IT24240: Messages delivered to JMS message listeners running in migrationmode after the JMS Connection has been stopped.

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 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