APAR status
Closed as program error.
Error description
An MQ classes for JMS application configures multiple MessageListeners for asynchronous message consumption where all of the associated "javax.jms.MessageConsumer"objects are created from the same JMS Session. The application then sets the MessageListener on one of the MessageConsumers to the value "null" on one thread, just ahead of a call to: javax.jms.Connection.stop() made by another thread on the same parent JMS Connection. The call to stop() completed, but messages are still being delivered to one or more of the other MessageListeners.
Local fix
Stop the JMS Connection before changing (including setting the value to null) the JMS MessageListener. This is the more appropriate behaviour as per the JMS Specification which states that Connection.close() is the only method call that can be made against a MessageConsumer with a MessageListener configured. It is also encouraged that applications should be migrated away from using the MQ classes for JMS "migration" mode messaging, and use "normal" mode where possible, where the problem does not occur.
Problem summary
**************************************************************** USERS AFFECTED: This issue affects applications who use the MQ classes for JMS that are configured to run in migration (v6) mode, as defined in the following Knowledge Center page: https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com. ibm.mq.con.doc/q123670_.htm Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: The MQ classes for JMS when running in migration (also known as v6) mode used an internal flag to record the state of a JMS MQSession was before stopping asynchronous message delivery while changing a MessageListener. Once the MessageListener on the MessageConsumer had been changed, the state flag was returned to its state when method call: javax.jms.Session.setMessageListener(MessageListener) was initially called. If on another thread, the application also called in parallel: javax.jms.Connection.stop() in between the changing and resetting of the Session's status flag, the MQ classes for JMS in migration mode would have resumed asynchronous message consumption even though the user had requested that the Connection to be stopped.
Problem conclusion
The MQ classes for JMS for migration mode have been updated to ensure that the operations of updating a MessageConsumer's MessageListener and stopping a JMS Connection have sufficient locking in place to prevent the problem described in this APAR from occurring. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v8.0 8.0.0.10 v9.0 LTS 9.0.0.4 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
IT24240
Reported component name
IBM MQ BASE MP
Reported component ID
5724H7251
Reported release
800
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2018-02-28
Closed date
2018-04-05
Last modified date
2018-04-05
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
IBM MQ BASE MP
Fixed component ID
5724H7251
Applicable component levels
[{"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:
05 April 2018