IBM Support

IT20599: Intermittent failure to receive JMS messages after message listener set to null in migration(v6) mode


You can track all active APARs for this component.


APAR status

  • Closed as program error.

Error description

  • The WebSphere MQ classes for JMS client, when used by
    applications that connects to an MQ queue manager using
    migration / v6 mode to receive message asynchronously, can
    discard a received message without delivering it to the
    application, if the application sets its JMS MessageListener to
    null without first stopping the JMS Connection.

Local fix

  • Call stop() on the JMS Connection before changing or nulling the
    JMS MessageListener used to receive messages asynchronously.

Problem summary

  • ****************************************************************
    This issue affects applications that use the:
      - WebSphere MQ V7.5 classes for JMS
    which connect to an MQ queue manager using the
    migration/compat/v6 mode of operation and call:
    without first stopping the JMS Connection in use.
    Platforms affected:
    When an MQ classes for JMS application connects to a queue
    manager using the migration/v6 provider mode and configures a
    JMS MessageListener to receive messages asynchronously, an
    internal "SessionAsyncHelper" thread is used to poll for
    messages.  This thread uses, by default, MQGET calls with a five
    second timeout when polling.  When the JMS MessageListener is
    first configured by the application and the JMS Connection
    started, this SessionAsyncHelper thread is started.
    If a null JMS MessageListener is set while the JMS Connection is
    still in started state, via a call to:
    the JMS MessageListener is removed, but the SessionAsyncHelper
    thread isn't paused.  As such, it could potentially be in a
    waiting MQGET call for a message.
    In the scenario where a message then arrived on the destination
    being polled by the SessionAsyncHelper thread, the
    SessionAsyncHelper consumed it, acknowledged it (if appropriate)
    but then had nowhere to deliver it.  As a result, the message
    was discarded without being delivered to the application. The
    SessionAsyncHelper thread would then stop, so subsequent message
    will be available to synchronous receive calls.
    This problem does not occur if the JMS Connection is stopped
    before the JMS MessageListener is changed.  This is because the
    call to stop() on the JMS Connection call will block until the
    SessionAsyncHelper thread has been paused.  Note that according
    to the JMS specification, close() is the only call that can be
    made against the message consumer when another thread (the
    SessionAsyncHelper) is controlling the JMS Session.  As such,
    correctly behaving applications should call stop() on the JMS
    Connection before changing or nulling a MessageListener
    configured on a MessageConsumer.

Problem conclusion

  • The MQ classes for JMS migration/v6 provider mode product code
    has been updated to synchronize the SessionAsyncHelper thread's
    polling MQGET with wait API call and the updating of a JMS
    MessageListener associated with a MessageConsumer.  As a result,
    a call to:
    will not return while the SessionAsyncHelper thread is
    processing an MQGET call.  Once the MQGET call returns, the
    application thread changing the JMS MessageListener can
    Note that the JMS MessageListener is now cached prior to a
    SessionAsyncHelper thread's MQGET call.  This means that if it
    consumes a message at the same time an application thread is
    changing or nulling the MessageListener on the MessageConsumer,
    an attempt to deliver the message to the original
    MessageListener will still be attempted.
    The fix is targeted for delivery in the following PTFs:
    Version    Maintenance Level
    The latest available maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    If the maintenance level is not yet available information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'

Temporary fix


APAR Information

  • APAR number


  • Reported component name


  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date


  • Closed date


  • Last modified date


  • 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


  • Fixed component ID


Applicable component levels

[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCPQ63","label":"APAR \/ Maintenance"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.5","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 August 2018