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.
Archive for the ‘WebSphere MQ’ Category
Being presented with my “10 year pen” at a departmental meeting on Monday seems like a good excuse for a bit of a retrospective on my career with IBM…
There has been a recent push to get more of the WebSphere development team out in to the blogosphere in the run up to the release of V7 of the Application Server. The standard form seems to be to advertise new blogs on the WebSphere Community Blog. So far there is one covering WebSphere and Java Persistence, and likely to be of particular interest to readers of this blog, one on WebSphere and Messaging. Note that the latter doesn’t cover WebSphere MQ (see this blog if that’s your area of interest) but rather the default messaging provider in WebSphere Application Server. Expect to see lots of good material on some of the new features and make the most of the chance to interact with the development team. Whilst on the subject of new blogs, if DataPower is your bag then you can read all about a forthcoming book from some of my ex-ISSW colleagues here.
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 184.108.40.206 (220.127.116.11 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.
Andrew is plugging the draft of his Redbook Connecting Enterprise Applications to WebSphere Enterprise Service Bus over on SOA Tips ‘n’ Tricks and rightly so as it’s well worth a look. If you thought that WebSphere ESB was just about SOAP/HTTP then this book should set you straight. It covers details of integration via WebSphere MQ, JDBC and HTTP and connecting to CICS. I’ve been working on the labs for the corresponding ITSO Workshop rolling out later this year.