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

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