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