APAR status
Closed as program error.
Error description
When using the IBM MQ classes for JMS to consume messages asynchronously using a JMS Message Listener, if stop() is called on the JMS Connection or JMS Context, from which the asynchronous consumer was created while a message is just about to be delivered to the application, further message delivery the Message Listener does not resume should the application then later call start().
Local fix
Option 1: Close the previously MessageConsumer or JMSConsumer and create a new one in its place that has the JMS Message Listener set on it. Option 2: Use a transacted JMS Session or JMS Context from which the asynchronous message consumer is created.
Problem summary
**************************************************************** USERS AFFECTED: This issue affects applications that: - use the IBM MQ classes for JMS to create asynchronous message consumers (via a JMS Message Listener), - connect to a queue manager using the CLIENT transport mode, - and call the stop() and then start() methods on the JMS Connection or JMS Context object from which the message consumer was created. This issue does not affect applications that are using the MQ classes for JMS in compatibility mode (also known as migration or v6 mode). Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: When an JMS application configures a JMS Message Listener to consume messages asynchronously, the MQ classes for JMS client uses the following mechanism to deliver messages to the application: - The thread starting the JMS Connection / Context sends an MQCTL command to the MQ queue manager to activate the asynchronous consumer callback. - A "request for messages" flow is sent to the queue manager indicating the MQ classes for JMS client is ready to receive a message asynchronously for delivery to the application. - The internal "Remote Receive Thread" associated with the TCP/IP connection that the application thread is using will receive the MQ message sent from the queue manager and put it onto an internal proxy queue. - An internal "Dispatch Thread" will then be notified of the received message, obtain a "Dispatch Lock", take the MQ message off the proxy queue, transform it into a JMS Message and deliver it to the onMessage(javax.jms.Message) callback method of the application's JMS Message Listener. - Once the onMessage(javax.jms.Message) callback has returned, the Dispatch Thread then checks the status of the connection handle used by the asynchronous consumer callback. If it is still in a STARTED state, then the Dispatch Thread sends another request for messages flow to the queue manager indicating the next message can be streamed to the MQ classes for JMS client when it is available. - The Dispatch Thread then releases the DispatchLock and awaits notification that another message is pending delivery to the JMS Message Listener. If an application calls stop() on the JMS Connection or JMS Context at the same time as the Remote Receive Thread is notifying the Dispatch Thread that a message for delivery has been received and is available on the internal proxy queue, the stop() thread and the Dispatch Thread compete for the Dispatch Lock. In the case where the application thread calling stop() obtained the Dispatch Lock first, an MQCTL flow was sent to the queue manager to suspend the asynchronous consumer callback. The state of the connection handle used by the asynchronous consumer callback was updated and marked as STOPPED. The thread then dropped the Dispatch Lock allowing the Dispatch Thread to process the message delivery before it returns the stop() call. After the onMessage(javax.jms.Message) call then returned, the Dispatch Thread found that the state of the connection handle was STOPPED and so did not send another request for message flow to the queue manager. Once the application then called start() on the now stopped JMS Connection or Context, the MQ classes for JMS did not send a request for message flow to the queue manager and so, although the asynchronous consumer callback was again activated, the queue manager was not informed that the MQ classes for JMS was ready for message streaming to resume. As such, no more messages were delivered to the application's JMS Message Listener.
Problem conclusion
The MQ classes for JMS have been updated to set some state on the internal proxy queue when the connection handle used by an asynchronous consumer callback is stopped such that a request for messages flow is sent to the queue manager when it is started again. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v8.0 8.0.0.8 v9.0 CD 9.0.4 v9.0 LTS 9.0.0.2 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
IT17340
Reported component name
WMQ BASE MULTIP
Reported component ID
5724H7251
Reported release
800
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-10-04
Closed date
2017-06-22
Last modified date
2017-06-22
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
5724H7251
Applicable component levels
R800 PSY
UP
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0.0.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
22 June 2017