IBM Support

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

Subscribe

You can track all active APARs for this component.

 

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":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
01 June 2017