IBM Support

IT20943: A MQ JMS MessageConsumer.receive(long) call may not immediately return when closing the consumer

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.


APAR status

  • Closed as program error.

Error description

  • An application is using the IBM MQ classes for JMS, and issues
    the method call:
    which instructs the MQ classes for JMS to wait a maximum of 1
    hour for a message to become available on the destination if one
    is not present immediately.
    After 10 minutes, the application elects to close the
    MessageConsumer in order to shut the application down, which is
    expected to interrupt and abort the receiving thread's receive
    However this does not happen - the receiving thread is not
    interrupted, and remains in the receive call for the remainder
    of the wait interval.
    The net result is that the application takes far longer to shut
    down than was desired.

Local fix

Problem summary

  • ****************************************************************
    This issue affects IBM MQ classes for JMS applications that are
    making use of the message receive method calls:
      javax.jms.MessageConsumer.receive(long interval)
    where the JMS Connection which was used to create the associated
    JMS Session is connecting to the queue manager using the CLIENT
    transport type, over a CHANNEL with the configuration:
    and the TCP/IP connection associated with the JMS Connection has
    been disconnected from the queue manager, but work under the
    associated JMS Session is continuing to be undertaken.
    Platforms affected:
    When connecting to the queue manager using the CLIENT transport
    type (that is to say, using TCP/IP to communicate with the queue
    manager), a 'hconn' is associated with both the JMS Connection
    and Session(s).
    These 'hconns' share a physical TCP/IP socket in accordance with
    the queue manager's CHANNEL property 'SHARECNV', which defaults
    to the value 10.  This means that in the default configuration,
    there can be up to 10 'hconns' sharing same physical TCP/IP
    socket for communication with the queue manager.
    The 'hconns' are assigned to the TCP/IP socket on a first come,
    first serve basis.  There is no correlation with the
    distribution of 'hconns' over the available TCP/IP sockets, and
    the relationship of the JMS Connections and Sessions.
    As a consequence, it is possible that a 'hconn' for a JMS
    Connection, and the associated JMS Session's 'hconn' are
    communicating with the queue manager over separate TCP/IP
    Once created, the communication over the JMS Connection's
    'hconn' is limited to a small number of uses.  One such use is
    when connected over a channel with the configuration
    'SHARECNV(1)', is to interrupt another thread which is being
    used to consume a message, using a MessageConsumer created from
    a JMS Session which in turn was created from the JMS Connection.
    The problem being addressed by this APAR is that if an
    application was operating over an unreliable network, it was
    possible that the JMS Connection's associated TCP/IP socket (and
    hence, its 'hconn'), becomes disconnected from the queue
    manager.  In this scenario, a MessageConsumer associated with
    the now-disconnected JMS Connection would continue to function,
    however there was no mechanism to interrupt a waiting
    MessageConsumer if the application attempted to end the receive
    call prematurely.
    To explain this in more detail with an example, consider the
    following code snippets and times when events might occur:
    00:00 Create a Connection, connecting over a SHARECNV(1) channel
    00:01 Create a JMS Session
    00:02 Create a JMS MessageConsumer
    00:03 Initiate a long (1 hour) receive call
    00:05 After 5 minutes, the TCP/IP socket associated with the JMS
    Connection is closed.  No Connection
    "javax.jms.ExceptionListener" has been configured, so this
    disconnection is silent from the application's perspective.
    00:15 After 15 minutes, the application attempts to shut down,
    and expects to interrupt the receiving thread by closing the
    In order to interrupt the receiving thread in the SHARECNV(1)
    configuration, the Connection's 'hconn' must be used to notify
    the queue manager that the receiving thread is to be released.
     As the Connection's 'hconn' was no longer connected to the
    queue manager, this notify message did not reach the queue
    manager.  No exception was returned to the closing thread -
    instead the close() method call completed and the receiving
    thread was still blocked in the receive, for the duration of the
    receive call.
    01:03 After 1 hour, the receive call completed and the the
    thread returned.
    The problem exists for several ways of attempting to interrupt
    the MessageConsumer, including:

Problem conclusion

  • The IBM MQ classes for JMS have been updated such that when this
    scenario is detected, and the notify message fails to be sent to
    the queue manager, the IBM MQ classes for JMS will attempt to
    establish a new connection to the queue manager in order to flow
    the notify request.
    Once the notify request has been made, this new connection will
    then be disconnected.
    If this re-connection attempt fails for some reason, the socket
    associated with the 'hconn' for the JMS Session will then be
    closed.  This closing action will be reported to the receiving
    thread in the form of a JMS Exception, reporting a:
    error message.
    The action of re-connecting to the queue manager to issue this
    notify message is expected to be expensive in terms of the time
    taken to establish a new connection to the queue manager.  This
    may be observed as the call to:
    taking longer than is typical for your environment.  Therefore
    if your application regularly issues the close() JMS method call
    in order to interrupt long running receive calls, without
    re-establishing the JMS Connection, it is suggested that your
    application also register an ExceptionListener against the
    associated JMS Connection, in order to be notified when the JMS
    Connection is detected to be disconnected from the queue
    manager, and then not continue to perform receive calls against
    associated MessageConsumers without the application closing the
    existing JMS artifacts and creating new ones to initiate further
    receive calls.
    The fix is targeted for delivery in the following PTFs:
    Version    Maintenance Level
    v9.0 LTS
    v9.1 CD    9.1.3
    v9.1 LTS
    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":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"9.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
28 February 2019