IBM Support

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

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

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":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
22 June 2017