IT42384: MQ-JMS application hangs when consuming a message from a v6.0 queue manager

APAR status

• Closed as program error.

Error description

• An web servlet running within WebSphere Application Server 9.0
  attempts to consume a message from an MQ queue running on a
  v6.0.2.3 queue manager on AIX.
  
  A web servlet issues the JMS API call:
  
    javax.jms.MessageConsumer.recieve(long timeout);
  
  Occasionally it is observed that the method call does not
  return, and exceeds the provided timeout value - the method call
  appears to have hung.
  
  It is also observed that the thread running this method call is
  using the maximum CPU available to the single thread.
  
  When the WebSphere Application Server hung thread detector
  determines that this servlet thread may be hung, it reports a
  message of the following form in the SystemOut.log file:
  
  00000040 ThreadMonitor W   WSVR0605W: Thread "WebContainer : 7"
  (0000010d) has been active for 662803 milliseconds and may be
  hung.  There is/are 1 thread(s) in total in the server that may
  be hung.
  	at
  com.ibm.mq.jmqi.remote.util.RemoteCommsBufferItem.free(RemoteCom
  msBufferItem.java:135)
  	at
  com.ibm.mq.jmqi.remote.impl.RemoteSession.receiveOneTSH(RemoteSe
  ssion.java:902)
  	at
  com.ibm.mq.jmqi.remote.impl.RemoteSession.receive1stGetReplyTSH(
  RemoteSession.java:1521)
  	at
  com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiGetMessageWithProps(Rem
  oteFAP.java:9875)
  	at
  com.ibm.mq.jmqi.remote.api.RemoteFAP.MQGET(RemoteFAP.java:9566)
  	at
  com.ibm.mq.ese.jmqi.InterceptedJmqiImpl.MQGET(InterceptedJmqiImp
  l.java:1227)
  	at com.ibm.mq.ese.jmqi.ESEJMQI.MQGET(ESEJMQI.java:430)
  	at
  com.ibm.msg.client.wmq.compat.base.internal.MQSESSION.MQGET(MQSE
  SSION.java:975)
  	at
  com.ibm.msg.client.wmq.compat.base.internal.MQQueue.getMsg2Int(M
  QQueue.java:1355)
  	at
  com.ibm.msg.client.wmq.compat.base.internal.MQQueue.getMsg2(MQQu
  eue.java:961)
  	at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.get
  Message(MQMessageConsumer.java:2788)
  	at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.rec
  eiveInternal(MQMessageConsumer.java:4635)
  	at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.rec
  eive(MQMessageConsumer.java:4109)
  	at
  com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receiveIn
  boundMessage(JmsMessageConsumerImpl.java:1073)
  	at
  com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receive(J
  msMessageConsumerImpl.java:691)
  	at
  com.ibm.mq.jms.MQMessageConsumer.receive(MQMessageConsumer.java:
  209)
  ...
  

Local fix

• Migrate the queue manager to a supported version of MQ where
  this
  issue is not encountered.
  

Problem summary

• ****************************************************************
  USERS AFFECTED:
  Users of the IBM MQ classes for Java/JMS which are consuming
  messages from a queue manager which is not respecting the
  negotiated maximum transmission established when the application
  established a CLIENT transport connection (using TCP/IP) to the
  queue manager.
  
  One example of such a system is with a v6.0.2.3 queue manager
  running on AIX.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  When an application connects to a queue manager over a CLIENT
  transport connection (meaning, communicating with the queue
  manager over a TCP/IP connection), the MQ API in the client
  application (eg. IBM MQ classes for JMS) negotiates the
  communication protocol to use to pass data back and forth with
  the queue manager.
  
  One of the facets of this negotiation is the maximum
  transmission length - that is to say the maximum amount of data
  which the queue manager or client application will send over
  TCP/IP in any single MQ packet.
  
  The MQ classes for Java/JMS then creates its local storage
  structures based on this maximum transmission length.
  
  
  When communicating with a v6.0.2.3 queue manager, it was found
  that a small range of message sizes resulted in the queue
  manager sending over a MQ transmission packet over TCP/IP which
  exceeded the negotiated maximum size.
  
  This had the effect of hanging the application's request method
  to consume the message from the queue, eg. when using the MQ
  classes for JMS API, the method:
  
    com.ibm.mq.jms.MQMessageConsumer.receive(long timeout)
  
  would not return the message to the application, and would
  instead consume the maximum single threaded CPU available to it,
  looping internally in the code.
  
  A Java thread dump of this thread would show various thread
  stacks, including the following examples:
  
  Example 1:
  com.ibm.mq.jmqi.remote.impl.RemoteSession.receiveOneTSH(RemoteSe
  ssion.java:895)
  com.ibm.mq.jmqi.remote.impl.RemoteSession.receive1stGetReplyTSH(
  RemoteSession.java:1521)
  com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiGetMessageWithProps(Rem
  oteFAP.java:9875)
  com.ibm.mq.jmqi.remote.api.RemoteFAP.MQGET(RemoteFAP.java:9566)
  ... .... ...
  
  Example 2:
  com.ibm.mq.jmqi.remote.util.RemoteCommsBufferItem.free(RemoteCom
  msBufferItem.java:135)
  com.ibm.mq.jmqi.remote.impl.RemoteSession.receiveOneTSH(RemoteSe
  ssion.java:902)
  com.ibm.mq.jmqi.remote.impl.RemoteSession.receive1stGetReplyTSH(
  RemoteSession.java:1521)
  com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiGetMessageWithProps(Rem
  oteFAP.java:9875)
  com.ibm.mq.jmqi.remote.api.RemoteFAP.MQGET(RemoteFAP.java:9566)
  ... ... ...
  

Problem conclusion

• The MQ classes for Java/JMS have been updated such that when the
  condition where the queue manager has sent more data over TCP/IP
  in a single MQ packet than was negotiated, the MQ classes for
  Java/JMS will throw an exception when attempting to consume the
  message instead of hanging.
  
  The exception contains a MQRC 2195 'MQRC_UNEXPECTED_ERROR', and
  is of the form:
  
  javax.jms.JMSException: MQJMS2002: failed to get message from MQ
  queue.
  at
  com.ibm.msg.client.wmq.compat.jms.internal.ConfigEnvironment.new
  Exception
  at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.get
  Message
  at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.rec
  eiveInternal
  at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.rec
  eive
  at
  com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receiveIn
  boundMessage
  at
  com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receiveNo
  Wait
  at com.ibm.mq.jms.MQMessageConsumer.receiveNoWait
  at MyApplication.mymethod
  Caused by: com.ibm.mq.MQException: MQJE001: Completion Code '2',
  Reason '2195'.
  at com.ibm.msg.client.wmq.compat.base.internal.MQQueue.getMsg2
  at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.get
  Message
  ... 7 more
  
  
  An FDC is also generated which provides more details about the
  issue.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v9.1 LTS   9.1.0.15
  v9.2 LTS   9.2.0.10
  v9.3 LTS   9.3.0.5
  v9.x CD    9.3.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

  IBM MQ BASE MP

• Fixed component ID

  5724H7271

Applicable component levels