Preventive Service Planning
WebSphere MQ Version 7.0 introduced many internal changes to the product to add in all the additional functionality it provides. With the maturing of this functionality due to maintenance activity, it has been evident that customers who have moved to recent maintenance levels such as 18.104.22.168 or above have benefitted from the fixes which have been included. Analysis of recent problems reported by our clients has shown that they frequently report problems which are already available in these more recent Fix Packs. While there are always costs to applying maintenance due to test and other quality assurance activities for our customers, there are many benefits to staying up to date with WebSphere MQ maintenance.
One area of the product which has benefitted in particular from maintenance recently is the WebSphere MQ classes for Java/JMS, where the cumulative effect of fixes delivered into recent Fix Packs have allowed customers applying recent levels such as 22.214.171.124 or 126.96.36.199 as preventative maintenance to avoid problems which other customers on earlier maintenance levels are reporting to IBM. Users of the MQ resource adapter (RA) in WebSphere Application Server users would see similar benefit by updating to 188.8.131.52 or higher to obtain an updated MQ RA.
This document provides a list of the more repeatedly seen symptoms and associated APARs which users of the WebSphere MQ classes for Java/JMS V7.0, including the WebSphere MQ Resource Adapter, have reported to IBM Support.
It is not intended to represent the complete list of issues which are known about, and included in fix packs. For that information, see the Fix list for WebSphere MQ Version 7.0:
This document will be updated with APARs which are worthy of note, as they are highlighted by the IBM Support teams.
Application Thread Hangs
- IZ72627 - fixed in 184.108.40.206
Multi-threaded JMS applications receiving messages from the same queue may hang where message sizes are greater than 4kB.
- IZ94412 - fixed in 220.127.116.11
Asynchronous consumption (used by JMS MessageListeners) stops consuming messages from the queue included in 18.104.22.168), giving the impression that the receiving thread has hung.
- IZ90144 - fixed in 22.214.171.124
Readahead functionality unreliable, leading to message consumers not receiving messages, giving the impression that the receiving thread has hung. Also see IV09815, included in 126.96.36.199 for a related queue manager side issue.
- IC76544 - fixed in 188.8.131.52
Asynchronous non-durable JMS subscribers only receive one message from subscription, giving the impression that the receiving thread has hung.
- IV00757 - fixed in 184.108.40.206
Thread deadlock occurs while closing JMS MessageConsumers or Sessions, while a MessageListener is communicating with the queue manager.
High CPU Usage
- IZ86170 - fixed in 220.127.116.11
Maxed out CPU usage when using multi-threaded JMS applications to pull messages from the same queue where message sizes are greater than 4kB.
- IZ94777 - fixed in 18.104.22.168
When using migration mode (channel property SHARECNV=0, connected to a V6 queue manager or using the PROVIDERVERSION=6 property), if a connection is disconnected by the network topology, the disconnection is not registered with the calling application, and a single thread consumes the available CPU.
Message Conversion Issues
- IC72897 - fixed in 22.214.171.124
JMS applications upgraded from V6 may have encountered problems associated with data conversion, either the received message bytes were different in V7 to those seen in V6, or the queue manager was unable to convert the messages in V7 issuing error messages.
This APAR switches the default JMS message conversion behaviour back to that of V6.
Uneven Distribution of Messages
- IZ97460 - fixed in 126.96.36.199
When multiple JMS asynchronous consumers are monitoring a queue (for example, in the case of application server activation specifications), the message distribution is not even between all the JVMs. For more information, please see the URI below:
Note that this fix is a code change to the queue manager and not the WebSphere MQ classes for JMS.
WebSphere Application Server V7.0 using an out of date WebSphere MQ Resource Adapter
- By default when a WebSphere Application Server V7.0 profile is created at the WebSphere Application Server V188.8.131.52 level (for example by the product install profile creation tool), the WebSphere MQ Resource Adapter V184.108.40.206 is installed in such a way as to remain at this level regardless of the WebSphere Application Server fix pack level which is then applied.
The version of the WebSphere MQ Resource Adapter which is included in each WebSphere Application Server fix pack is documented in the table in technote "Which version of WebSphere MQ is shipped with WebSphere Application Server ?"
To ensure that your application server uses the appropriate version of the WebSphere MQ Resource Adapter, you will need to run a script which updates the application server profile to point to the fix pack installed version of the resource adapter. This procedure is documented in the WebSphere Application Server product documentation,
- IZ93547 - fixed in 220.127.116.11
An application server is using multiple Activation Specifications, or Listener Ports (within WebSphere Application Server), configured to consume messages from WebSphere MQ queues. The application server system log reports a warning message JMSCC0108, and messages are not being consumed and processed by the associated Message Driven Beans (MDBs).
|Application Servers||WebSphere Application Server||Java Message Service (JMS)||AIX, HP-UX, i5/OS, Linux, Solaris, Windows, z/OS||7.0|
WebSphere MQ WMQ WAS WebSphere Application Server