IT18207: A MESSAGE PUT WITH MQPMO_NO_CONTEXT CANNOT BE REQUEUED TO A BACKOUT QUEUE IF POSIONOUS BY JMS

APAR status

• Closed as program error.

Error description

• If an MQ classes for JMS application receives a message that
  does not contain any timestamp information indicating when the
  message was originally put and that message was a poison
  message, a java.lang.NullPointerException is thrown and the
  message is now requeued to the backout requeue queue.  The Java
  exception stack is as follows:
  
  java.lang.NullPointerException
  com.ibm.msg.client.wmq.common.internal.messages.WMQMessageBase._
  getJmsFolder
  com.ibm.msg.client.wmq.common.internal.messages.WMQSendMarshal.w
  riteMQRFH2
  com.ibm.msg.client.wmq.common.internal.messages.WMQSendMarshal.w
  riteMessageProperties
  com.ibm.msg.client.wmq.common.internal.messages.WMQSendMarshal.c
  onstructMessageBuffers
  com.ibm.msg.client.wmq.common.internal.messages.WMQSendMarshal.e
  xportMQMDAndMessageBuffers
  com.ibm.msg.client.wmq.common.internal.messages.WMQSendMarshal.e
  xportMQMD
  com.ibm.msg.client.wmq.internal.WMQPoison$PoisonMessage.calculat
  eMqmdAndBuffers
  com.ibm.msg.client.wmq.internal.WMQPoison$PoisonMessage.getMQMD
  com.ibm.msg.client.wmq.internal.WMQPoison$PoisonMessage.access$1
  600
  com.ibm.msg.client.wmq.internal.WMQPoison.put
  com.ibm.msg.client.wmq.internal.WMQPoison.backoutRequeue
  com.ibm.msg.client.wmq.internal.WMQPoison.handlePoisonMessage
  com.ibm.msg.client.wmq.internal.WMQPoison.handlePoisonMessage
  com.ibm.msg.client.wmq.internal.WMQConsumerShadow.getMsg
  com.ibm.msg.client.wmq.internal.WMQConsumerShadow.getMsg
  com.ibm.msg.client.wmq.internal.WMQSyncConsumerShadow.receive
  com.ibm.msg.client.wmq.internal.WMQSession.loadMessageReference
  com.ibm.msg.client.jms.internal.JmsSessionImpl.consume
  
  This can occur when the MQ classes for JMS are consuming a
  poison message that does not have an RFH2 with a <jms> folder
  and was originally put with the MQPMO_NO_CONTEXT option, such
  that the MQMD of the MQ message does not have values for the
  PutDate and PutTime fields.
  

Local fix

• Configure the MQ classes for JMS application to operate in
  migration mode (v6 style), for example by setting the value of
  the SHARECNV property on the server-connection used by the
  application to 0.
  

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects all users of the:
  
    - WebSphere MQ V7.1 classes for JMS and JCA Resource Adapter
    - WebSphere MQ V7.5 classes for JMS and JCA Resource Adapter
    - IBM MQ V8 classes for JMS and JCA Resource Adapter
    - IBM MQ V9 classes for JMS and JCA Resource Adapter
  
    - WebSphere Application Server V8, V8.5 and V9 MQ messaging
  provider
  
  who try to consume a poison message (where the backout count on
  the message is greater than the backout threshold defined on the
  queue from which it was consumed) and the message does not
  contain any timestamp information for when the message was put.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  When the MQ classes for JMS created an RFH2 header for a
  message, it expected that a JMSTimestamp property had already
  been configured on the JMSMessage object, indicating the point
  at which the message was sent.  The MQ classes for JMS then
  checked whether the value associated with the JMSTimestamp
  property was suitable (non-negative) before writing it into the
  <jms> folder of the RFH2 header with the attribute <Tms>.
  
  In the case of poison messages that do not contain any timestamp
  information indicating when the message was put, for example
  because there is no RFH2 header on the message (or no <jms>
  folder in the RFH2 header) and the message was put with the put
  message option "MQPMO_NO_CONTEXT" such that the PutDate and
  PutTime fields of the MQMD are blank, then the JMSTimestamp
  property on the message would be null.  This caused a
  java.lang.NullPointerException to be thrown.
  

Problem conclusion

• The MQ classes for JMS product code has been updated to tolerate
  null JMSTimestamp and JMSExpiration properties on JMSMessage
  objects when the RFH2 header and message properties handle
  structure is being constructed.  If the JMSTimestamp property on
  a message is null, then no "Tms" message property is written
  into the <jms> folder of the RFH2 header or associated with the
  message properties handle on the MQ message that is constructed
  and put to the queue manager.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v7.5       7.5.0.8
  v8.0       8.0.0.7
  v9.0 CD    9.0.2
  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

  5724H7241

Applicable component levels