Browsed by
Month: July 2012

Funnel Cloud

Funnel Cloud

A funnel cloud formed off the coast of Herne Bay this evening, and I managed to get a grainy shot on my phone.

It got a bit of attention on Twitter, where I learnt the difference between a “mini tornado” and a “funnel cloud”, the main one being that there is no such thing as a mini tornado – a funnel cloud is a funnel cloud until it hits land (when it becomes a tornado) or water (when it becomes a water spout).

Funnel Cloud on Wikipedia

Update: ITV Meridian mention of the funnel cloud.  They asked if they could use my picture, and are crediting me, but that’s not actually my photo.  Mine is much more blurry.

Update 2: An article on the KM Kent Online website.  The picture and story suggest that the funnel cloud did touch down at sea, making it a water spout, I think.

Update 3: My photos in the Media Gallery.  Shaun at was amongst the first to show an interest in my original tweet, and promptly asked if he could post my picture on his site.  He’s included the full-zoom tight crop, along with the 2 uncropped versions.  They’re all quite rubbish, as photos go, so it’s not surprising that someone took the time to vote them as worth just 1 or 2 stars… 🙂

Spring JMX and Tomcat 7 Parallel Deployments

Spring JMX and Tomcat 7 Parallel Deployments

Spring JMX

The Spring framework makes it really easy to expose attributes and operations on your beans via JMX by the use of a couple of really simple annotaions.

First, you need some boilerplate config in your Spring context XML, like this:

And then you just need to sprinkle some @ManagedResource, @ManagedAttribute and @ManagedOperation annotations around your class, like this:

    objectName = "bean:name=MyServiceImpl",
    description = "MyService JMX Stuff")
public class MyServiceImpl implements MyService {

    @ManagedAttribute(description = "Counter attribute.")
    public long getCounter() {
        return counter.get();

When deployed to Tomcat, you should be able to look at your attributes and exercise your operations via any old JMX client (e.g. jconsole or VisualVM).

Tomcat 7 Parallel Deployments

Parallel Deployment” is a new-ish feature in Tomcat 7 which allows different versions of a webapp to be deployed side-by-side. It’s very simple in operation. You deploy a war file with a name like my-funky-webapp##001.war, and then another with a name like my-funky-webapp#002.war, and existing sessions get routed to version 001, whilst new sessions get bumped over to version 002. The version string can be any String; Tomcat decides which is the newer version by just sorting them as Strings, so xxx#9.war is newer than xxx#10.war.

Add them together and…

…parallel deployments stop working.

Specifically, newer versions of the webapp never start taking sessions.

This is probably really obvious to a lot of people, but it stumped me for a little while. The problem is that the Spring JMX annotations try to register an MBean according to the @ManagedResource annotations. The previous version’s MBean is still there (the old version stays deployed until any existing sessions expire). By default, the Spring JMX behaviour is to fail fast on deployment, which prevents the whole of the new version of the webapp from deploying.

The fix is simple. Just add a registration attribute to the <mbean-export> to get the new MBeans to replace the old ones, like this:

Using Flot to generate a barchart against a time-based x-axis

Using Flot to generate a barchart against a time-based x-axis

Wow – there’s a title to excite the hoards, eh?  This might read as a kind of ‘note-to-self’, because that’s pretty much what it is – sorry about that. It might be useful to someone though, I suppose.

Flot is a jQuery-based charting library, as previously used by the StackExchange family of sites for things like their reputation chart before Jeff et al decided that pretty graphs of your rep weren’t actually that useful.

My particular requirement was to chart a count of ‘stuff’ against hours of the day, so pretty graphs would be very useful. Here are some notes on how to do that.

Let’s start with a screenshot.  Here’s what I ended up with:

Flot relies on jQuery, so first of all we need to include that in our page, like so:

Then a link to the Flot library itself:

Flot works by replacing the contents of a ‘placeholder’ div, so stick one of those on the page, wherever you want the chart to appear. It needs an id so that Flot can find it, and a height and width, so that Flot can scale the chart appropriately:

Finally, we need to kick the chart into life, which I did like this:


Lines 4-9 are setting up the data to plot. This is just proving the chart library works, so I’ll be generating this with from the view’s model at some point, but you get the idea. When plotting against a time axis with Flot, you need to generate a Javascript timestamp, hence the new Date(...).getTime() stuff.

Line 11 calls the Flot function to generate the chart, selecting the placeholder div, and passing in the d array of values.

Line 12 tells Flot that we want a barchart. barWidth: 1000*60*60*0.5 stipulates that the bars should be ‘half-an-hour’ wide. Since we’re charting in milliseconds (that’s what Javascript timestamps are based on), we need to tell Flot how many of them each of our bars should take up. Without this, the barchart would be generated with 1 pixel wide bars – not very pleasing on the eye.

Line 13 tells Flot to interpret the x values of our data as Timestamp values, so we get a useful ‘8:00’ instead of a not-so-useful ‘1342314544452’.

And that’s about it. Some things to remember:

  • Flot doesn’t do axis labels. If you want one, you’ll need to put it on your page yourself, which is a bit sucky.
  • I got mixed results when experimenting with the barWidth parameter. Too narrow, and the x-axis scale started to get screwed up. A 50/50 ratio between bar and ‘gap’ seemed to look ok and not cause other problems.
  • There’s a whole bunch of other parameters that I didn’t use. Here’s the full Flot API documentation.
  • If you’re using Eclipse and including Flot in your project, then you’ll probably end up with a couple of Javascript errors and metric shedload of Javascript warnings. I’m not in the business of fixing other people’s code (especially when it seems to work just fine, thankyouverymuch), so I just stopped Eclipse whinging by excluding the Flot (and jQuery) files from the Eclipse Javascript source. See this StackOverflow answer for details.