How to handle order of messages in JMS

Question

I am reviewing a client server application written in java. The server receives JMS messages and processes them but the messages can come in unexpected order, a cancel can arrive before an order message. How do you handle such a case? Do you do it in the mdb?

Any strategies or patterns for this kind of scenario?

Thanks

FF

Answer 1

So far I know, this is refereed to as "out-of-order" delivery and is part of the quality of service (QoS) attributes of the JMS system. I don't think it's part of the JMS specification, but some provider support it maybe. That will depend on the particular JMS implementation you use.

Note however that JMS is meant to distribute messages to several consumers in a way to distribute the load. If message have to be delivered in an ordered fashion this is not possible -- it basically lead to serialization of the message delivery and message could not be processed concurrently.

The wikipedia says it better than me:

JMS queue A staging area that contains messages that have been sent and are waiting to be read. Note that, contrary to what the name queue suggests, messages don't have to be delivered in the order sent. If the message driven bean pool contains more than one instance then messages can be processed concurrently and thus it is possible that a later message is processed sooner than an earlier one. A JMS queue guarantees only that each message is processed only once.

Out-of-band cancel request is not easy to achieve with JMS then. Two ideas:

• Store a ticket which corresponds to each message in a database could be used to cancel message easily. When the message is delivered, the MDB check if the corresponding ticket is still valid. If yes, proceeds further, if not, drop the message.
• Try to set the MDB pool size to one. Maybe in this case, the delivery will be ordered. Changing the pool size is app. server specific, but most of them support per-bean pool size.

Othersie, have maybe a look at the message store pattern. It's anyway worth checking the EAI website.

Answer 2

Your system will be a lot more flexible if it can cope with the out-of-order messages. The pattern I've used to solve this in the past is to use a delay queue (on a system that processed 8 million messages-per-day in the financial world).

In your example, if I received a delete for an order I hadn't received yet, I'd delay it for a period of time and retry. If I still knew nothing about the order I'm being asked to delete, I'd raise some sort of error (reply to the original sender, send a message to a special error queue, ...).

As to the implementation of the delay queue, this can be another JMS queue with a service that can accept messages to be delayed. It then periodically reads the delayed messages and checks if the delayed time period has expired and re-submit the message to the original destination queue.

Answer 3

I second the advice about checking the EAI site, and the book it is based on (a fantastic text on MOMs and MOM patterns).

Personally I'd investigate the Resequencer, though.