IT17340: JMS Message Listener does not resume asynchronous message delivery after connection.start() is called.

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