IBM Support

IT17680: JMS application running in migration mode takes a long time to stop a JMS connection

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

  • A MQ-JMS application is using the MQ classes for JMS v8.0.
    It has created a single JMS Connection, and has used this
    Connection to create a number of JMS Sessions, from which it has
    created several MessageListeners.  The JMS Connection is
    connected to a v6.0 queue manager.
    The asynchronous MessageListeners have been consuming messages,
    before all the queues were emptied.  The MessageListeners are
    still active, but not processing due to having no messages on
    their source queues to consume.  The application then issues a
    stop command on the Connection:
    and it is observed that it takes a long time to complete, in the
    order of several minutes.  This was not the case when using the
    WebSphere MQ classes of for JMS v6.0.2.9, where this method call
    completed almost immediately.

Local fix

  • Reducing the polling interval will decrease the time it takes
    for  the Connection.stop() method call to complete.
    This is a property of the MQConnectionFactory, and can be
    modified by updating the property:
    from its default value of 5000ms (5 seconds).
    Alternatively it can be  programmatically altered by calling the
    Note that decreasing this value increases the number of MQGET
    calls which the asychronous MessageListeners make to consume
    messages from the queue, in periods where there is insufficient
    messages on the queue to keep the MessageListener from running
    at its maximum speed.

Problem summary

  • ****************************************************************
    Users of the MQ classes for JMS, who are:
      (1) Running in migration mode meaning one or more of:
        (a) Connecting to a v6 or earlier queue manager
        (b) Using a channel with the SHARECNV attribute to be the
    value '0'
        (c) Setting the ProviderVersion property of the
      (2) Using a JMS Connection which has had multiple JMS
    MessageListeners created under it, and there are insufficient
    messages on the queue to keep the MessageListener constantly
      (3) Invoking "Connection.stop()"
    Platforms affected:
    As of APAR IZ70015 which went into WebSphere MQ, the
    method call:
    will not return to the application until the asynchronous
    message consumption associated with the MessageListeners has
    completed, in accordance with the JMS specification.
    When the v7.0 and beyond MQ classes for JMS is running in
    migration mode, the underlying mechanism employed to consume
    messages asynchronously is to perform a series of polling MQGET
    requests, using a wait time the value defined in the
    "pollingInterval" on the ConnectionFactory used to create the
    JMS Connection, which defaults to 5000ms (5 seconds).
    There is no mechanism to interrupt this MQGET in migration mode,
    so when the Connection.stop() method call is made, it will not
    return until this 5 second MQGET has completed.
    If multiple MessageListeners have been created from a single JMS
    Connection, the Connection.stop() method call will wait for each
    one to complete sequentially.  For example, if there are 10
    MessageListeners running from the JMS Connection, and the
    average time to wait is 2.5 seconds (half the default
    pollingTime interval), it might be expected to wait an average
    of (10 x 2.5) 25 seconds.  This wait time increases linearly
    with the number of MessageListeners which are running from this
    JMS Connection.

Problem conclusion

  • The MQ classes for JMS has been optimised such that when it is
    running in migration mode, when the application makes the method
    all of the MessageListeners complete a single cycle of their
    polling MQGET, and then stop.  This means that the average wait
    time might now be expected to be in the region of 2.5 seconds,
    regardless of the number of MessageListeners running against the
    JMS Connection.
    Note that if the application calls:
    without first calling Connection.stop(), such that the
    MessageListeners are still active, a long wait will likely be
    encountered again.  The optimisation associated with this APAR
    has ONLY been applied to the Connection.stop() API call.  If
    performance in closing is an issue for you in this scenario, it
    is suggested that you first call:
    followed by:
    which will then complete quickly.
    The fix is targeted for delivery in the following PTFs:
    Version    Maintenance Level
    v9.0 CD    9.0.2
    v9.0 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

  • R800 PSY


[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
01 June 2017