As part of an ongoing effort to better brand Interface21 as a company, I’m deprecating my individual company blog and moving to the Interface21 team blog. You’ll find it at http://blog.interface21.com. All of my currently existing posts are there and I’ll be posting from there very shortly.

I realize that this may mean some updates to RSS feeds in the like, but I think it provides a much greater value and simply listening to my ramblings. In addition to me you’ll have the likes of Keith Donald, Colin Sampaleanu, Mark Fisher, and the rest of the Interface21 staff posting and generally improving the community.

Again, sorry for the inconvience, but I’m pretty sure you’ll be happier in the end.

In a project that I used to work on we had a system that would receive messages from a device and make decisions on whether that information would be passed to the user. There were multiple decision levels and one of the problems we always found ourselves asking was if a message was being lost on it’s way through the system.

Before we moved to Spring, it was nearly impossible to tell the answer to that question. Attempts were made to use logging, but the sheer volume of messages that decisions were made on made it tedious at best. Other attempts were made using debuggers but a combination of the volume and the timing changes led to only intermittent success.

Unfortunately I left before we could implement a more suitable solution but if I had, here is what it probably would have been like. At the end I’ll discuss some of the extensions that might be useful in this kind of effort.

To start, we’ve got a set of interfaces and their implementations:

This is a very simple example, but the gist is that using the fowardCall() method messages are passed 50% of the time to the next child component (ascending numerical order in this case). Note that there is no logic involving tracing in these POJOs.

To implement our tracing behaviors, we’d like to have a set of counters; one for each component. In addition we’d like ways to reset the counters, start and stop monitoring, and determine if monitoring is happening. To do this we implement a class with the counters.

The methods and their contents are pretty straight forward for this class. What may be new to you are the annotations on this class. These annotations are used by Spring’s JMX support to automatically build up MBean management interfaces when each bean is deployed to the JMX MBeanServer.

• ManagedResource: Declares that this class should be exposed as a JMX MBean
• ManagedAttribute: Declares that the JavaBean property represented by this getter/setter should be a MBean attribute. You need to annotate both the getter and setter if you want read and write access to this attribute.
• ManagedOperation: Declares that this method should be exposed as an MBean operation

Finally it’s a matter of wiring the whole thing together. First, we wire together the components that make up the flow. Next we declare the aspects that will put the tracer on each of the components. In this case we are using the very sweet AspectJ pointcut language. Finally we setup the JMX exporter to autodetect instances of classes that have the @ManagedResource annotation on them.

The next things that we need to do is have a driver class. In this case the driver class just sends a message at some random delay under 750ms.

In my case, I’m going to run this application with the Java VM Management running since it gives me a free MBean server (and I like the pretty memory graphs). If you haven’t heard of this, it’s a system property in Java 5 VMs that causes the VM to use JMX to manage itself. It has beans for memory consumption, threading, and a million other things. You start it simply by putting -Dcom.sun.management.jmxremote on the command line of your running application. In another nifty Java 5 addition, I’m going to use jconsole to display my results.

Based on my rusty math skills, over the long term, I’d expect to see Component 1 called 100%, Component 2 called 50%, and Component 3 called 25% of the time. Lets see:

It’s good to see that I remember my probabilities right. The best part is this still meets good design principals. For example, none of the components know anything about the tracing because that’s not what they do. As well, all of the tracing requirements for this subsystem are contained in one class and have one implementation meeting the 1:1 requirements to implementation goal of AOP. Finally, with the ability to turn off the tracing, any performance impact is more or less neutralized. I know, I know incrementing an integer isn’t that expensive, but if you’re tracing did something expensive, it’s nice to have and you don’t have to worry if you want to send it into production; you can simply disable the monitoring until your customer calls in for support.

So the graphs sure are pretty and maybe even tell you stuff if you know your expected percentages, but what else could you do? How about the last 100 messages to go by and their decisions? How about a log of the reason that a message was dropped? How about correlation between drop decisions and the absence of a message at the end of the pipe? Wouldn’t it be nice to know that a message had been lost (perhaps due to a threading issue) because you never intentionally dropped it but it didn’t make it to the end within 500ms of its entry? Along that same line, how about an email to the admin if the time it takes to get from one end of the pipe to the other gets over 250ms?

The tracing/monitoring possibilities are endless (and pluggable!). What will you do with it?

And of course, the source code.

With the release of Spring 1.1 the Spring community was given it’s first taste of JMS support. This support included exception translation, message conversion, and a template class much like JdbcTemplate. This support also took care of domain unification between the JMS 1.0.2 and 1.1 specs. The centerpieces of this support are the JmsTemplate class and it’s JMS 1.0.2 counterpart JmsTemplate102.

This support was a great improvement over using the raw JMS APIs to do enterprise messaging. However it did have a shortcoming; the JmsTemplate only supported synchronous reception of messages using the JmsTemplate.receive() methods. This behavior worked well for many people but the vast majority of users of ended up rolling their own implementations of an asynchronous consumer. In short, they wanted what EJB 2 called Message Driven Beans.

But no longer will users do without. With the release of 2.0M1 and the final 2.0 release later, native support for asynchronous reception of JMS messages has been added. The JmsTemplate is still used for sending of messages at his always been, but it has now been joined by subclasses of AbstractMessageListenerContainer such as DefaultMessageListenerContainer, SimpleMessageListenerContainer, and ServerSessionMessageListener.

Let’s take a look at how to use these MessageListenerContainers. The first step is to create a class that can receive the messages. To do this, one must create a class that implements the MessageListener interface.

Once you have that, you’ll need a message producer. This code is the same as it was back before Spring 2.0, so if you have code that does this already, it should not require any changes.

Next, you need to configure your context to create a MessageListenerContainer that routes messages to this bean. You’ll notice that I’m using ActiveMQ implementation classes in this example. This just happens to be one of many JMS implementations and happens to be the one that I’m most familiar with.

I’m going to skip it for now, but obviously you’ll need to have an MQ started, and a main method that bootstraps your context. I’ve added an archive of the project from this example so that you can see the rest of the code if you need it.

Finally, you just need to run your application and take a look at the output.

One thing to note is that so far we’ve been dealing with asynchronous reception with a single consumer thread. It is possible to multithread to your consumers (remember that you’ll still have to make them stateless or thread-safe) using the concurrent consumers property of the MessageListenerContainer.

One thing I’d like to note (from my own painful experience) is to make sure that you don’t use concurrent consumers with a Topic. Remember that in a JMS topic all messages are delivered to all consumers on a topic. This means that if you have concurrent consumers on a topic, all of them will receive the same message; typically something that you’d want to avoid. However, if you’re using a queue, obviously this would dispatch each new message to the consumers in a round-robin fashion.

So, there you have it. It isn’t very flashy and is probably very similar to something you may have written at some point, but now all you have to do is use it, you don’t have to maintain it. Let me also say that this is just the tip of the iceberg. The MessageListenerContainers have the ability to take part in transactions, use custom threadpools (like the ones provided with an app server) with the new Spring TaskExecutorabstraction, and even expose the native JMS session to the consumer. Each of those things is a topic for another post though.