IBM Support

IT38423: MQ JMS clients fail to reconnect when using automatic client reconnection after a network break.

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 MQ 9.2 classes for JMS application connects to a queue
    manager and specifies the Connection Factory properties:
    
    CLIENTRECONNECTOPTIONS = ANY
    CLIENTRECONNECTTIMEOUT=1
    
    to enable automatic client reconnection. After connecting to the
    queue manager, and being disconnected, the MQ classes for JMS
    attempt to reconnect to the queue manager and time out. This
    results in a JMSException being thrown back to the application.
    After the application reconnects to the queue manager, it is
    disconnected again. However, this time the application hangs -
    the MQ classes for JMS do not reconnect to the queue manager,
    and no exception is thrown back to the application.
    
    Javacores collected when the issue occurs shows that the
    internal Remote Reconnect Thread, which is responsible for
    performing the reconnection, is stuck in a call to
    Thread.sleep(). An example of the call stack for the Remote
    Reconnect Thread when it is in this state is shown below:
    
    "JMSCCThreadPoolWorker-3" J9VMThread:0x00000000034CB500,
    omrthread_t:0x0000000012B5C390,
    java/lang/Thread:0x00000000E061A708, state:CW, prio=5
    ....
      Java callstack:
        at java/lang/Thread.sleep(Native Method)
        at java/lang/Thread.sleep(Thread.java)
        at
    com/ibm/mq/jmqi/remote/impl/RemoteReconnectThread.bestHconn(Remo
    teReconnectThread.java)
        at
    com/ibm/mq/jmqi/remote/impl/RemoteReconnectThread.run(RemoteReco
    nnectThread.java)
        at
    com/ibm/msg/client/commonservices/workqueue/WorkQueueItem.runTas
    k(WorkQueueItem.java)
        at
    com/ibm/msg/client/commonservices/workqueue/SimpleWorkQueueItem.
    runItem(SimpleWorkQueueItem.java)
        at
    com/ibm/msg/client/commonservices/workqueue/WorkQueueItem.run(Wo
    rkQueueItem.java)
        at
    com/ibm/msg/client/commonservices/workqueue/WorkQueueManager.run
    WorkQueueItem(WorkQueueManager.java)
        at
    com/ibm/msg/client/commonservices/j2se/workqueue/WorkQueueManage
    rImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementat
    ion.java)
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects users of the MQ 9.2 classes for JMS, who have
    applications that use the automatic client reconnection
    functionality.
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    The internal RemoteReconnectThread within the MQ classes for
    JMS, which was designed to handle reconnecting any broken
    connections to a queue manager, was sleeping for an extremely
    long duration of time under specific circumstances such as the
    system operating with only one connection which had been closed.
    This sleep rendered the automatic client reconnection
    functionality useless for a long period of time, meaning any new
    connections that were made are no longer being monitored to
    detect whether or not they have closed and need re-establishing.
    
    This was due to the fact that the thread was performing no
    internal checks to determine whether or not the sleep duration
    was both necessary, and thus also for a suitable duration.
    

Problem conclusion

  • An extra check has been added to the internal
    RemoteReconnectThread to determine whether or not it needs to be
    sleeping at all. This means that if it does need to sleep, it
    will do so for the appropriate duration of time, as to remain
    responsive.
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v9.2 LTS   9.2.0.5
    v9.x CD    9.2.5
    
    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

    IT38423

  • Reported component name

    MQ BASE V9.2

  • Reported component ID

    5724H7281

  • Reported release

    920

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2021-09-20

  • Closed date

    2021-10-19

  • Last modified date

    2021-10-19

  • 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

    MQ BASE V9.2

  • Fixed component ID

    5724H7281

Applicable component levels

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

Document Information

Modified date:
20 October 2021