APAR status
Closed as program error.
Error description
An IBM MQ Managed File Transfer agent is acting as the destination agent for a managed transfer that has been configured with a transfer recovery timeout. When processing the managed transfer, the agent generates an ABEND file containing the information shown below: ... Level: p910-006-200703 ... Thread: 41 (ReceiverEventListenerTransferIdentifier) Class: com.ibm.wmqfte.thread.FTEThread ... Method: uncaughtException Probe: ABEND_001 Cause: java.lang.NullPointerException java.lang.NullPointerException at com.ibm.wmqfte.transfer.eventlistener.ReceiverTransferEventListe ner$EventRunnable.run (ReceiverTransferEventListener.java:175) at java.lang.Thread.run(Thread.java:820) at com.ibm.wmqfte.thread.FTEThread.run(FTEThread.java:70) and then shuts itself down.
Local fix
Problem summary
**************************************************************** USERS AFFECTED: This issue affects all users of IBM MQ Managed File Transfer who have agents that process managed transfers which have a transfer recovery timeout specified. Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: MQ 9.0.1 CD introduced some new functionality that allowed managed transfers that have been in recovery for longer than a specified period of time to be automatically cancelled. When this happens, the source agent for the managed transfer will send a message to the destination agent indicating that the managed transfer has been cancelled, and then mark the managed transfer as "Failed". Some more information about this functionality can be found in the Setting a timeout for recovery of stalled transfers topic in the MQ sections of IBM Knowledge Center. The URI for this topic in the MQ 9.2.x section of IBM Knowledge Center is https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.2.0/com. ibm.mq.adm.doc/recovery_timeout.html Now, the following sequence of events led up to the issue reported in this APAR occurring: - A source agent received a managed transfer request, and the transfer recovery timeout functionality was enabled for that managed transfer. - As part of the processing of that managed transfer request, the source agent sent an initial transfer negotiation message to the destination agent, and waited for a response.. - After waiting for the period of time specified by the agent property "maxTransferNegotiationTime", the source agent hadn't received the response from the destination agent and so put the managed transfer into recovery. - The source agent then continued to wait for the response from the destination agent. - After waiting for the period of time specified by the transfer recovery timeout, the source agent still hadn't received any response from the destination agent. As a result, it sent another message to the destination agent, indicating that the managed transfer had been cancelled, and marked the managed transfer as "Failed". - Some time later, the main CommandHandler thread within the destination agent picked up the initial transfer negotiation message from the source agent, registered the managed transfer with its state store and then started an internal thread to perform the negotiation. - Shortly afterwards, the destination agent's CommandHandler thread received the message indicating that the managed transfer had been cancelled and so removed details of it from its internal state store. - A few milliseconds later, the internal thread tried to get details about the negotiated parameters for the managed transfer from the state store, and use them during the negotiation process. However, the transfer was no longer present in the state store. As a result, the agent generated an ABEND containing the following information: Thread: 41 (ReceiverEventListenerTransferIdentifier) Class: com.ibm.wmqfte.thread.FTEThread ... Method: uncaughtException Probe: ABEND_001 Cause: java.lang.NullPointerException java.lang.NullPointerException at com.ibm.wmqfte.transfer.eventlistener.ReceiverTransferEventListe ner$EventRunnable.run() at java.lang.Thread.run() at com.ibm.wmqfte.thread.FTEThread.run() and then shut itself down.
Problem conclusion
To resolve this issue, IBM MQ Managed File Transfer has been updated so that: - If an internal thread within a destination agent is negotiating a managed transfer. - And the internal thread detects that the managed transfer is no longer in the agent's state store when it tries to access the negotiated parameters which should be used. then the internal thread will stop the negotiation process. This ensures that the managed transfer is stopped cleanly, and prevents the ABEND reported in this APAR from occurring. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v9.1 LTS 9.1.0.8 v9.2 LTS 9.2.0.2 v9.x CD 9.2.2 The latest available MQ 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
IT34591
Reported component name
IBM MQ MFT V9.1
Reported component ID
5724H7272
Reported release
910
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2020-10-19
Closed date
2021-01-22
Last modified date
2021-01-22
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 MFT V9.1
Fixed component ID
5724H7272
Applicable component levels
[{"Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"910"}]
Document Information
Modified date:
23 January 2021