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 number
IT18207
Reported component name
WMQ BASE MULTIP
Reported component ID
5724H7241
Reported release
750
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-12-01
Closed date
2017-01-31
Last modified date
2017-03-10
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
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSDEZSF","label":"IBM WebSphere MQ Managed File Transfer for z\/OS"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.5","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
31 March 2023