IBM Support

IT36308: Exception containing reason code 2009 is thrown even though an application is still connected to a queue manager

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

  • An IBM MQ classes for Java application  is connecting to a z/TPF
    queue manager using the CLIENT transport. The MQ channel that
    the application is using to communicate with the queue manager
    has the "heartbeat interval" (HBINT) attribute set to the value
    1. When the application calls the method
    MQDestination.get(MQMessage, MQGetMessageOptions) to get a
    message from the queue. passing in an MQGetMessageOptions object
    which contains:
    
    - The option MQGMO_WAIT
    - And a wait interval of 30 seconds.
    
    an MQException containing MQ reason code 2009
    (MQRC_CONNECTION_BROKEN) is thrown even though the application
    is still connected to the queue manager.
    

Local fix

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects two categories of users:
    
    Category 1:
    -------------
    Users of the IBM MQ classes for Java who have applications that
    connect to a queue manager:
    
    - Using the CLIENT transport.
    - and a channel mode earlier than WebSphrere MQ 7.0 (because the
    channel has been configured with the SHARECNV attribute set to
    the value 0, for example)
    
    and call one of the following methods to get a message from
    either a queue or a topic:
    
    - MQDestination.get(MQMessage message, MQGetMessageOptions
    getMessageOptions)
    - MQDestination.get(MQMessage message, MQGetMessageOptions
    getMessageOptions, int maxMsgSize)
    
    where the MQGetMessageOptions object passed into the method
    contains the option MQGMO_WAIT and a wait interval.
    
    
    Category 2:
    -------------
    Users of the IBM MQ classes for JMS who have applications that
    connect to a queue manager:
    
    - Using the CLIENT transport.
    - and IBM MQ messaging provider migration mode.
    
    and call the method:
    
    - MessageConsumer.receive(long timeout)
    
    to get a message from a JMS destination.
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    The MQ classes for Java and classes for JMS use an internal
    component called the Java Message Queueing Interface (JMQI) to
    communicate with a queue manager. If an application is:
    
    - Connecting to a queue manager using the CLIENT transport.
    - And is using a channel mode earlier than WebSphere MQ 7.0
    (because the channel has been configured with the SHARECNV
    attribute set to the value 0, or the queue manager is a z/TPF
    queue manager using an old version of the MQ FAP, for example)
    
    then the JMQI will set up a non-multiplexed TCP/IP connection
    for the application to use (when using the MQ classes for JMS,
    this method of communication is known as IBM MQ messaging
    provider migration mode).
    
    For non-multiplexed connections, the MQ channel attribute
    "heartbeat interval" (HBINT) provides the approximate time in
    which heartbeat packets flow from the queue manager to the JMQI,
    and back again, when an application has performed an MQGET
    operation which includes a wait interval.
    
    
    Now, the JMQI used to use the following logic when determining
    how long to wait for a heartbeat packet from the queue manager
    over a non-multiplexed connection:
    
    - If the HBINT was set to a value less than 60 seconds, then the
    JMQI would wait for "2 times the HBINT".
    - If the HBINT was 60 seconds or more, then the JMQI would wait
    for a period of "one minute plus the value of the HBINT".
    
    This meant that:
    
    - If an application had connected to a queue manager using a
    non-multiplexed connection.
    - And had called a method which performed an MQGET operation,
    such as MQDestination.get(MQMessage message, MQGetMessageOptions
    getMessageOptions) or MessageConsumer.receive(long timeout),
    specifying a wait interval greater than 2 seconds.
    - And the HBINT attribute was set to 1 second
    
    then the JMQI would wait for 2 seconds to receive some data
    (either an MQGET reply, or a heartbeat request) from the queue
    manager. If no data was received within 2 seconds, then the JMQI
    would assume that the queue manager was no longer available and
    throw an exception containing MQ reason code 2009
    (MQRC_CONNECTION_BROKEN) back to the application
    
    Because the HBINT attribute specified the approximate time in
    which heartbeat packets were flowed from the queue manager, it
    was possible that the following situation could occur:
    
    - The JMQI flowed an MQGET API call, specifying the
    GetMessageOption MQGMO_WAIT and a wait interval greater than 2
    secondsl, to the queue manager.
    - It then waited for 2 seconds for some data (either an MQGET
    reply or a heartbeat request) from the queue manager.
    
    - The queue manager received the MQGET API call from the JMQI.
    As there were no messages on the queue, the queue manager waited
    for one to arrive.
    - One second later, there were still no messages on the queue.
    As a result, the queue manager sent a heartbeat request to the
    JMQI.
    
    - At the point at which the heartbeat packet was sent, the JMQI
    had been waiting for just over a second to receive data from the
    queue manager. The heartbeat packet hadn't arrived by the time
    the JMQI timed out, and so it assumed that the queue manager was
    no longer available.
    - This caused the JMQI to throw an exception containing MQ
    reason code 2009 (MQRC_CONNECTION_BROKEN) back to the
    application.
    
    
    If the JMQI subsequently flowed another MQ API call to the queue
    manager over the same connection (such as an MQCLOSE API call
    because the application was closing off its connection handles
    as part of its exception handling, for example), then the queue
    manager would potentially report a protocol error as it was
    expecting a heartbeat response rather than the MQ API call.
    

Problem conclusion

  • To resolve this issue, the JMQI has been updated so that if:
    
    - It is connected to a queue manager using the CLIENT transport
    over a non-multiplexed connection.
    - And the "heartbeat interval" (HBINT) attribute of the MQ
    channel that the JMQI is using is set to a value of 2 seconds or
    less.
    - And an application using the non-multiplexed connection calls
    a method which performs an MQGET operation, such as
    MQDestination.get(MQMessage message, MQGetMessageOptions
    getMessageOptions) or MessageConsumer.receive(long timeout).
    
    then the JMQI will wait for 5 seconds for data to arrive from
    the queue manager. This means that it will wait for a suitable
    amount of time to receive any heartbeat packets, or MQGET
    replies, that are sent by the queue manager before deciding that
    the queue manager is no longer available.
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v9.2 LTS   9.2.0.3
    v9.x CD    9.2.3
    
    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

    IT36308

  • Reported component name

    MQ BASE V9.2

  • Reported component ID

    5724H7281

  • Reported release

    921

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2021-03-22

  • Closed date

    2021-04-22

  • Last modified date

    2021-06-29

  • 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

    MQ BASE V9.2

  • Fixed component ID

    5724H7281

Applicable component levels

[{"Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU029","label":"Software"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"921"}]

Document Information

Modified date:
30 June 2021