APAR status
Closed as program error.
Error description
An MQ JMS application attempts to consume a message from a queue using the JMS method call: javax.jms.MessgeConsumer.receive(long timeout); using a small timeout value (for example, 2 milliseconds), within a Java virtual machine which is very busy with multiple thread consuming system resources. The receive() attempt might return a 'null' object to the application without actually checking with the queue manager if there is a message available to be delivered to the application. MQ JMS trace shows no errors, just an early return from the receive() method.
Local fix
Call receiveNoWait(), or use a larger receive() wait interval to avoid this problem.
Problem summary
**************************************************************** USERS AFFECTED: Users of the IBM MQ classes for JMS who are invoking the methods: com.ibm.mq.jms.MQMessageConsumer.receive(long timeout) com.ibm.mq.jms.MQQueueReceiver.receive(long timeout) com.ibm.mq.jms.MQTopicSubscriber.receive(long timeout) where the specified timeout value is a small value (measured in milliseconds), such that several operations internally within the IBM MQ classes for JMS may exceed this specified timeout value. Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: The IBM MQ classes for JMS take a note of the time at which the "MessageConsumer.receive(long timeout)" method is invoked by an application, and removes the time it takes to perform some initial processing internally within the "com.ibm.mq.jms.MQMessageConsumer" class before invoking the lower level classes which request the message from the queue manager. This mechanism permits the MessageConsumer class to count down time spent waiting for the Connection to 'start' if it is initially in the 'stopped' state. However one consequence of this is that if the specified wait time is small (for example 1 or 2 milliseconds), there is a possibility that the time will be exceeded before requesting the message from the queue manager, even if the Connection is initially in the 'started' state. For a light or moderately loaded JVM, this processing typically takes much less than 1 millisecond. However if the JVM is particularly heavily loaded, for example when is trace is enabled, or when the amount of work waiting to occur exceeds the capacity of the system or the garbage collector pauses the JVM's threads temporarily, it can take more than 1 millisecond. In this scenario, the "MessageConsumer.receive(long timeout)" method returns a 'null' value the application, which matches the behaviour if the queue did not have any messages on it. This might falsely imply to the application that the queue is empty.
Problem conclusion
The IBM MQ classes for JMS have been updated such that when the method: com.ibm.mq.jms.MQMessageConsumer.receive(long timeout) is invoked and the Connection is in the 'started' state, if the JVM pauses sufficiently mid-processing to cause the timeout to expire before contact is made with the queue manager, a request for a message will still be issued but no wait time will be specified. This will ensure that if the "MessageConsumer.receive(long timeout)" returns a 'null' value back to the invoking application and the Connection is in the 'started' state, the application can be assured that there is no message on the queue matching the MessageConsumer's selection criteria. Note that while this APAR is listed as going into a MQ v9.0 fix pack, the issue was already addressed for MQ 9.0.0.0, and so does not affect MQ v9.0. The associated code change which is going into the v9.0 fix pack is to improve the serviceability of this piece of code function. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v8.0 8.0.0.6 v9.0 CD 9.0.1 v9.0 LTS 9.0.0.1 The latest available maintenance can be obtained from 'WebSphere MQ Recommended Fixes' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037 If the maintenance level is not yet available information on its planned availability can be found in 'WebSphere MQ Planned Maintenance Release Dates' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309 ---------------------------------------------------------------
Temporary fix
Comments
APAR Information
APAR number
IT15630
Reported component name
WMQ BASE MULTIP
Reported component ID
5724H7251
Reported release
800
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-06-07
Closed date
2016-06-20
Last modified date
2017-06-01
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
WMQ BASE MULTIP
Fixed component ID
5724H7251
Applicable component levels
R800 PSY
UP
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0.0.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
01 June 2017