APAR status
Closed as program error.
Error description
An MQ Managed File Transfer agent has been configured with a queue resource monitor that has been set up to trigger on complete message groups or individual messages not in a group. The source queue that the monitor is polling just contains individual messages not in a group. The monitor is configured with a batch size of 1, which means that it will submit a managed transfer for message that it finds on the queue during a poll. Intermittently, after the monitor has performed a poll and submitted managed transfer requests to the agent, the agent generates an FDC containing the following information and then shuts itself down: ---------------------------------------------------------------- ------ .... Probe: FFDC_004 ... Cause: com.ibm.wmqfte.statestore.FTEStateStoreException: BFGSS0004E: An internal error has occurred. Transfer ID <transfer identifier>. Required state CancelledNewTransfer. Actual state NegotiatingTransfer. com.ibm.wmqfte.statestore.FTEStateStoreException: BFGSS0004E: An internal error has occurred. Transfer ID <transfer identifier>. Required state CancelledNewTransfer. Actual state NegotiatingTransfer. at com.ibm.wmqfte.statestore.impl.FTEStateStoreImpl.validateState(F TEStateStoreImpl.java:1207) at com.ibm.wmqfte.statestore.impl.FTEStateStoreImpl.negotiateTransf er(FTEStateStoreImpl.java:447) at com.ibm.wmqfte.transfer.eventlistener.SenderTransferEventListene r$EventRunnable.run(SenderTransferEventListener.java:262) at java.lang.Thread.run(Thread.java:820) at com.ibm.wmqfte.thread.FTEThread.run(FTEThread.java:70) ... ---------------------------------------------------------------- ------
Local fix
Ensure that no transfer ID is duplicated, or reused.
Problem summary
**************************************************************** USERS AFFECTED: This issue affects users of: - IBM MQ 9.1 Managed File Transfer - IBM MQ 9.2 Managed File Transfer who have queue resource monitors that have been configured to trigger on complete message groups or individual messages not in a group. Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: When a queue resource monitor has been configured: - To trigger on complete message groups, or individual messages not in a group - And with a batch size of 1 then it will submit a managed transfer for every complete message group, or individual messages not in a group, that it finds during a poll. The transfer identifiers for these managed transfers will be: - The group identifier for complete message groups. - The message identifier for individual messages not in a group. When the agent picks up the managed transfer requests, it checks to see if there is already a managed transfer with that transfer identifier registered in its internal state store. If there is, then the new managed transfer request is rejected. If there isn't, then the agent will add details of the managed transfer into the state store and then start processing it. Now, if the source queue contained: - Two or more complete message groups with the same group identifier. - Two or more individual messages not in a group that had the same message identifier. then the queue resource monitor polling the queue would submit multiple managed transfers requests to the agent that had the same message identifier. Most of the time, the first managed transfer request would be registered with the agent's state store processed, and the subsequent ones would be rejected (which is the expected behavior). However, there was a small timing window which occasionally resulted in the following sequence of events occurring: - The internal CommandHandler thread within the agent picked up the first managed transfer request, and handed it off to an internal worker thread for processing. - The CommandHandler thread then picked up the second managed transfer request, and passed this on to another internal worker thread for processing. - The first internal worker thread locked the agent's state store, and checked to see if it contained an entry for the transfer identifier specified in the managed transfer request. - It didn't, so the thread unlocked the state store and decided to proceed with processing the request. - The second internal worker thread locked the agent's state store, and performed the same check. - The state store didn't contain an entry for the transfer identifier,, so this thread also decided to proceed with the request. - The first internal worker thread then added the an entry for the transfer identifier, along with details of the managed transfer, to the state store, and started the transfer negotiation. - The second internal worker thread also tried to add the entry for the transfer identifier to the state store. However, this attempt failed because the first internal worker thread had just added it. - As a result, the agent generated an FDC containing the following information: ---------------------------------------------------------------- ------ .... Probe: FFDC_004 ... Cause: com.ibm.wmqfte.statestore.FTEStateStoreException: BFGSS0004E: An internal error has occurred. Transfer ID <transfer identifier>. Required state CancelledNewTransfer. Actual state NegotiatingTransfer. com.ibm.wmqfte.statestore.FTEStateStoreException: BFGSS0004E: An internal error has occurred. Transfer ID <transfer identifier>. Required state CancelledNewTransfer. Actual state NegotiatingTransfer. at com.ibm.wmqfte.statestore.impl.FTEStateStoreImpl.validateState(F TEStateStoreImpl.java:1207) at com.ibm.wmqfte.statestore.impl.FTEStateStoreImpl.negotiateTransf er(FTEStateStoreImpl.java:447) at com.ibm.wmqfte.transfer.eventlistener.SenderTransferEventListene r$EventRunnable.run(SenderTransferEventListener.java:262) at java.lang.Thread.run(Thread.java:820) at com.ibm.wmqfte.thread.FTEThread.run(FTEThread.java:70) ... ---------------------------------------------------------------- ------ and shut itself down.
Problem conclusion
IBM MQ Managed File Transfer has been updated to ensure that internal worker threads add details of managed transfers to an agent's state store as soon as they decide that the managed transfer is OK to proceed. This means that if an agent receives two managed transfer requests that have the same transfer identifier, only one of the managed transfer requests will be processed. The other managed transfer request will be rejected (which is the expected behaviour). --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v9.1 LTS 9.1.0.11 v9.2 LTS 9.2.0.6 v9.x CD 9.3.0.0 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
IT35254
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-12-11
Closed date
2022-02-17
Last modified date
2022-04-13
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":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"910"}]
Document Information
Modified date:
14 April 2022