IBM Support

IT16587: MQ CLASSES FOR JAVA AND CLASSES FOR JMS APPLICATION THREADS HANG AFTER CHANNEL QUIECSED

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • An application using the WebSphere MQ classes for JMS is
    connecting to a queue manager using the CLIENT transport, and is
    receiving messages from a queue by calling the method:
    
    MessageConsumer.receive()
    
    While the application is running, the WebSphere MQ channel that
    the application is using to connect to the queue manager is
    quiesced. When this happens, the call to the method:
    
    MessageConsumer.receive()
    
    never returns and no exceptions are thrown. A Javacore taken
    when the issue occurs shows that the application thread is
    blocked in the method RemoteSession.exchangeTSH().
    

Local fix

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects two categories of user:
    
    1. Users of:
    
    - The WebSphere MQ V7.5 classes for Java who have an interim fix
    for APAR IT05967 installed.
    - The IBM MQ V8.0.0.3 (or later) classes for Java.
    - The IBM MQ V9.0.0.0 classes for Java.
    
    who have applications that connect to a WebSphere MQ queue
    manager using the CLIENT transport, and put or get messages from
    either queues or topics.
    
    2. Users of:
    
    - The WebSphere MQ V7.5 classes for JMS, who have an interim fix
    for APAR IT05967 installed.
    - The IBM MQ V8.0.0.3 (or later) classes for JMS
    - The IBM MQ V9.0.0.0 classes for JMS
    
    - The WebSphere MQ V7.5 resource adapter, who have an interim
    fix for APAR IT05967 installed.
    - The IBM MQ V8.0.0.3 (or later) resource adapter
    - The IBM MQ V9.0.0.0 resource adapter
    
    who have applications that connect to a queue manager using the
    CLIENT transport and WebSphere MQ messaging provider normal
    mode,, and put or get messages from either queues or topics.
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    When either of the mqsc commands:
    
    STOP CHANNEL()
    STOP CHANNEL() MODE(QUIESCE)
    
    are issued against a queue manager, the queue manager will
    perform a controlled shutdown of all of the instances of the
    channel specified. In order to do this, it will contact all of
    the WebSphere MQ Clients that are currently using an instance of
    that channel, informing them that the channel is being quiesced.
    The WebSphere MQ Clients will then perform the following
    behaviour:
    
    - All applications that are currently using that channel
    instance, who are in the middle of getting or putting a message
    at the time the command was run and have specified the
    MQGetMessageOption MQGMO_FAIL_IF_QUIESCE or the
    MQPutMessageOption MQPMO_FAIL_IF_QUIESCE should have the get or
    put operations interrupted with an error containing reason code
    2202 (MQRC_CONNECTION_QUIESCING).
    
    - All applications that are currently using that channel
    instance, who are in the middle of getting or putting a message
    at the time the command was run and have not specified the
    MQGetMessageOption MQGMO_FAIL_IF_QUIESCE or the
    MQPutMessageOption MQPMO_FAIL_IF_QUIESCE should be allowed to
    carry on using the channel instance as normal.
    
    - Any new applications that try to connect to the queue manager
    using that channel, or any additional threads inside existing
    applications which try to create a new connection to a queue
    manager using an instance of that channel, should be unable to
    connect and will receive an error containing WebSphere MQ Reason
    Code 2537 (MQRC_CHANNEL_NOT_AVAILABLE).
    
    APAR IT05967 introduced some new logic into the WebSphere MQ
    classes for Java and classes for JMS to ensure that this
    processing was carried out correctly. However, as a result of
    this change, a small timing window was introduced which would
    prevent the notification from being passed to an application
    thread which was waiting to receive data from the queue manager.
    As a result of this, the thread would block until the
    application was shut down, even though it had specified either
    the MQGetMessageOption MQGMO_FAIL_IF_QUIESCE or the
    MQPutMessageOption MQPMO_FAIL_IF_QUIESCE.
    
    Javacores taken at the time of the issue would show that the
    application thread was blocked in the method
    RemoteSession.exchangeTSH(). An example of the call stack for a
    thread that was getting messages from the queue manager when the
    issue occurred is shown below:
    
       java.lang.Object.wait()
    at java.lang.Object.wait()
    at com.ibm.mq.jmqi.remote.impl.RemoteSession.exchangeTSH()
    at
    com.ibm.mq.jmqi.remote.impl.RemoteProxyQueue.requestMessagesReco
    nnectable()
    at
    com.ibm.mq.jmqi.remote.impl.RemoteProxyQueue.requestMessages()
    at com.ibm.mq.jmqi.remote.impl.RemoteProxyQueue.flushQueue()
    at com.ibm.mq.jmqi.remote.impl.RemoteProxyQueue.proxyMQGET()
    at
    com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiGetInternalWithRecon()
    at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiGetInternal()
    at com.ibm.mq.jmqi.internal.JmqiTools.getMessage()
    at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiGet()
        :    :    :    :    :    :    :    :    :    :    :    :
       :    :
    

Problem conclusion

  • The WebSphere MQ classes for Java and classes for JMS have been
    updated to ensure that if a notification is received from a
    queue manager indicating that a channel is being quiesced. then
    all application threads using that channel instance which have
    specified either the MQGetMessageOption MQGMO_FAIL_IF_QUIESCE or
    the MQPutMessageOption MQPMO_FAIL_IF_QUIESCE will be interrupted
    and receive a JMSException containing WebSphere MQ reason code
    2202 (MQRC_CONNECTION_QUIESCING).
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v7.5       7.5.0.8
    v8.0       8.0.0.7
    v9.0 CD    9.0.2
    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

    IT16587

  • Reported component name

    WMQ BASE MULTIP

  • Reported component ID

    5724H7241

  • Reported release

    750

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2016-08-12

  • Closed date

    2017-01-26

  • Last modified date

    2017-03-10

  • 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

    5724H7241

Applicable component levels

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSDEZSF","label":"IBM WebSphere MQ Managed File Transfer for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.5","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
31 March 2023