WebSphere MQ non-ASF in WAS

Application Server Facilities (ASF) are the part of the JMS specification originally designed, amongst other things, to allow application server’s to retrieve messages for delivery to message-driven beans. Now WebSphere MQ’s ASF implementation had one significant flaw when it comes to multiple consumers pulling messages from the same queue. Each consumer was effectively browsing the queue looking for suitable messages and, when they found one, they then attempted to take a lock in order to consume the message. Unfortunately, inbetween the browse and the lock there’s a good chance that another consumer would have nipped in and stolen the message. This inefficient behaviour meant that you were unlikely to see linear scalability when adding multiple MDB consumers to a deep queue. As a result, some customers have switched their WebSphere Application Server listener port service to use non-ASF mode (the custom properties required for this can be found in the InfoCenter). This use a standard message consumer to poll the queue for messages – the downside being that you need a separate thread for each consumer.

There are, however, two relatively new innovations that make this picture more complex. Firstly, WebSphere MQ v7 brings to the distributed platform the browse-mark behaviour that previously existed only on the mainframe. This basically allows the connection consumer to lock messages as it browses the queue thereby ensuring that, when it decides to consume one, it is still available. Secondly, ASF is now old technology with the J2EE Connector Architecture 1.5 specification providing the preferred mechanism for integration between a JMS provider and application server MDBs. In WebSphere Application Server v7 this manifests itself as the WebSphere MQ resource adapter.

The good news is that, if you have a WebSphere MQ v7 queue manager, then the WebSphere MQ v7 JMS provider will automatically use the new browse-mark behaviour for both ASF and the resource adapter. If you are currently using non-ASF, you should therefore switch away from that to one of these two mechanisms when moving to WebSphere Application Server v7. However, if you still have a v6 queue manager and have previously been using non-ASF then you should continue to do and not switch to the resource adapter as this uses the same underlying technology as ASF.

Thanks to Ben Ritchie, Mark Whitlock and Matthew White for providing insight in to the new behaviour.

Leave a Reply