IBM Support

IT35254: Managed file transfer agent generates an FDC and terminates whenmultiple messages are processed having the same message id.

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

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