David Currie

Of my various publications, the one which seems to bring in the most questions at the moment is that relating to message groups in WebSphere MQ and how these are exposed through the JMS API. I should therefore confess that there are a couple of issues with the approach that the article describes.

The first issue relates to what happens when an attempt is made to receive a group but not all of the messages are currently available. The suggestion is made that, after a suitable pause, the receipt of the messages is rolled back and another attempt made. The problem with this is that it means some messages in a group may be rolled back more times that others and, in particular, some may get sent to the backout queue before the others. Consequently, it is necessary to either use message expiry or some cleanup process to ensure that the queue does not fill up with the remaining messages in these groups.

The second issue relates to performance. Message selection imposes a performance overhead. For WebSphere MQ JMS, message selection based solely on message or correlation identifier is performed on the server side. As soon as you start to perform more complex queries or use other properties (such as the JMSGroupID and JMSXGroupSeq used in the article), then the client browses the queue and performs the selection client side. Thanks to Eileen Dreyer in the development team for pointing me to the JMS performance report which, in sections 2.5 and 3.3, provides the information necessary to determine the overhead that selection can add.

Note that for WebSphere Message Broker it is possible to push message selection back to the server side and that the Service Integration Bus in WebSphere Application Server also performs message selection in the messaging engine.

This entry was posted on Thursday, November 9th, 2006 at 12:50 pm and is filed under WebSphere MQ. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.