IT15630: JMS receive() with a small timeout value can return a null even though messages are available on the queue

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 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