First impressions of IBM WebSphere MQ Low Latency Messaging

IBM has a rather new platform for messaging. It is called WebSphere MQ Low Latency Messaging (aka WebSphere MQ LLM). It was released on the fourth quarter of 2007 and sincerely it hasn’t much similarities with the well known WebSphere MQ (former MQ Series).

First of all, after installing it you will probably notice that there isn’t a service for starting up. Soon you notice that it is rather a library that provides messaging services. Actually, it is a native library (currently [v2.1] only available for Linux x86, Windows x86 and Solaris Sparc) that comes already with JNI bindings.

To make things even harder, there isn’t much documentation available (and it seems like IBM is still organizing its docs online).

But, IBM claims that it has shown impressive numbers on its benchmarks:

WebSphere MQ Low Latency Messaging has demonstrated very high throughput, one-to-many multicast messaging, which can deliver approximately one million 120-byte messages per second on Ethernet, close to three million 120-byte messages per second on InfiniBand, and more than 8 million smaller messages per second, all on common x86 servers. Testing has also measured very low latency of 30 microseconds for 120 byte messages delivered at 10,000 messages per second on InfiniBand or 61 microseconds on Ethernet (1)

Source: IBM press release

In its Java version, the main classes that you’ll interact when using WMQ LLM are:

• RUMInstance (available through RUMFactory)
• RMMInstance

For instance, RUM stands for Reliable Unicast Messaging and RMM stands for Reliable Multicast Messaging. As you can guess, RUM is used for Queue styled messaging and RMM for Topic styled messaging.

One of its drawbacks is that it still lacks a JMS based Resource Adapter but nothing denies you from rolling your own if you can’t wait for an official adapter from IBM.

I am planning to do some benchmarking against a regular MQ integrated application. As soon as I have the results I’ll post them over here.

Avoiding method timeouts in EJB Containers using Command Pattern with a JMS Queue

If you ever needed to run a complex processing in EJB that would take for example two minutes you probably have already faced the container time limitation for SessionBean methods.

This timeout (in contrast to what most think) isn’t there only to developer’s life harder. Actually, it is exactly the opposite: it is there to avoid that someone inadvertly implement a code that takes the whole server down (including your beloved application).

But there are times when long running operations are really necessary, for example a cache warmup.

MDBs are an exception

As in our project a few operations would easily violate this limitation we had to research a smart way of circumventing this limitation. During our research we found out this post on /dev/websphere blog. So we already knew that we would end up using a JMS Queue but having one Queue, MDB and so ever for each task would be a mess (not to mention that it was way too much work and not ellegant). So, that was when we came to the conclusion that what we needed was an way of having multiple tasks on top of the same infra-structure.

Command Pattern to the Rescue

We realized that by using an ObjectMessage that carried our Command object we would end up having a single queue that would handle all of our long running tasks. If there is specific context for the task processing we can have it stored in the Command Object (eg.: id of a purchase transaction that needs to be processed, or even the purchase object itself).

Sequence Diagrams for the solution

Let’s have an example, suppose we have a long running cleanup of a database that needs to be run in a timely manner. We would end up having the following flow of method calls:

JOB Submission on Working Queue

Having the Command object implement Runnable interface is a wise idea (to avoid having another interface that is almost a Runnable clone not to mention that future JavaEE Asynch beans will probably be implemented on top of Runnable interface).

The next important part is the JOB execution, which is depicted below:

JOB execution Working MDB

As mentioned on the notes, you need to be aware that the Transactional Context for the MDB MUST be Never, otherwise you’d avoid method timeouts but would still have transaction timeouts.

Another tricky part is splitting the long running task in smaller chunks that can execute under the method timeout.

As stated in the diagram, the LongRunningJOB code inside the run method is called inside the execution context of the MDB which is free from the method timeout limitation.

Signalling JOB return code

If you need to be notified that the JOB has finished its execution you’d need to have either another JOB passed as parameter to this JOB and it’ll be responsible of executing the code that would inform its return status OR have a message sent on a Temporary Queue OR the last option would be to submit a reply in another queue and have a CorrelationID link the request and the response message.