David Currie

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.

(more…)

Thanks once again to Paul Titheridge, this time for pointing me to this technote covering the use of the WebSphere MQ Java APIs in a J2EE/JEE environment. It seems that IBM does now support the use of the WebSphere MQ Java interfaces in a WebSphere Application Server environment (check the supported software for your release) but this technote provides you with lots of reasons why you shouldn’t! The Java interfaces do have functionality that isn’t currently available in the JMS API (for example message segmentation and important parts of message grouping) but that needs to be weighed carefully against the drawbacks. JMS should always be the default option unless you have a very good reason not to use it.

A question from a colleague had me wondering about the following restriction stated in the WebSphere Application Server Version 6.1 pre-reqs:

IBM WebSphere MQ 5.3 CSD 12 and IBM WebSphere MQ 5.3.1 for z/OS + PK10303 are supported for client mode connections only.

Fortunately, Paul Titheridge from the service team was able to provide me with an explanation. The use of the WebSphere MQ 5.3 JMS client is not supported in a Java 5 JVM which is, of course, what Version 6.1 of the application server is running on. For a client connection, you should use the WebSphere MQ Version 6 JAR files which are supported under Java 5, and also provide backwards compatibility when making a client connection to a Version 5.3 queue manager.

That said, with WebSphere MQ Version 5.3 due to go out of service at the end of next month then this is probably a largely academic discussion.

Updated: Paul’s explanation of the reasoning behind this statement is entirely correct but, it transpires, that statement is now out-of-date and only tells part of the story. WebSphere MQ 5.3 is now supported with WebSphere Application Server 6.1 providing you have at least CSD 13 of the former and 6.1.0.5 (6.1.0.6 on z/OS) of the latter. You also need to set the MQ_INSTALL_VERSION WebSphere variable as explained in the InfoCenter and this tech note. Thanks to Alasdair Nottingham for picking me up on this.

WebSphere Application Server has shipped with JAR files for the WebSphere MQ JMS provider since Version 5.0 as they were, at the time, required for the embedded messaging provider. However, if those JAR files do not match the version of WebSphere MQ you are using (as is the case with WebSphere Application Server V6.0 and WebSphere MQ V6) you may see error messages such as java.lang.NoSuchFieldError: msgToken. As documented on the support site and in the InfoCenter, on the server-side the correct thing to do is update the MQ_INSTALL_ROOT WebSphere variable to point to your real WebSphere MQ installation. What I haven’t seen documented anywhere is what to do in the case where you are using the WebSphere Application Server client container. In that scenario, you need to modify the JMS_PATH environment variable defined in the launchClient batch file in the application server bin directory.

I’ve mentioned one of my colleague Paul Titheridge’s articles before (on JMS Application Server Facilities) and he’s just started a new related series which is well worth taking a look at. This time Paul has turned his attention to the myriad of connection pool properties provided by WebSphere Application Server and what they mean when using WebSphere MQ as the JMS provider. As before, Paul has provided some thoroughly worked examples to help explain the implications of changing different values.