IBM Support

IT35322: Queue resource monitor submits two message-to-file transfers forthe same message or message group on consecutive polls.

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

  • A queue resource monitor has been defined on an MQ Managed File
    Transfer agent, and has been configured to:
    
    - Configured to trigger on individual messages not in a group,
    and complete message groups.
    - And submits message-to-file transfers for each individual
    message or message group that it triggers on.
    
    Occasionally, the resource monitor:
    
    - Detects a message or message group on one poll, and submits a
    managed transfer to process it.
    - And then detects the same message or message group on the next
    poll, and submits another message-to-file transfer to process
    it, even though the first message-to-file transfer hasn't
    completed yet.
    
    When this happens, one of two things occur:
    
    - Either the second message-to-file transfer completes
    successfully and the destination agent writes a zero-byte file.
    - Or the second message-to-file transfer is discarded, and the
    source agent generates an FDC containing the information shown
    below:
    
    Probe:   FFDC_001
    Cause:
    com.ibm.wmqfte.cmdhandler.FTECommandHandlerErrorException:
    BFGCH0005E: A problem occurred when registering a file transfer
    request.
    com.ibm.wmqfte.cmdhandler.FTECommandHandlerErrorException:
    BFGCH0005E: A problem occurred when registering a file transfer
    request.
      at
    com.ibm.wmqfte.cmdhandler.impl.FTECommandHandlerStateStoreImpl.p
    rocessFileTransfer(FTECommandHandlerStateStoreImpl.java:572)
      at
    com.ibm.wmqfte.cmdhandler.impl.FTECommandIntepreterFileTransfer.
    interpret(FTECommandIntepreterFileTransfer.java:335)
      at
    com.ibm.wmqfte.cmdhandler.impl.MessageHandlerImpl.externalMessag
    eHandler(MessageHandlerImpl.java:245)
      at
    com.ibm.wmqfte.cmdhandler.impl.MessageHandlerImpl.processCommand
    (MessageHandlerImpl.java:167)
      at
    com.ibm.wmqfte.cmdhandler.impl.FTECommandHandlerWorkerThread.pro
    cessCommand(FTECommandHandlerWorkerThread.java:276)
      at
    com.ibm.wmqfte.cmdhandler.impl.FTECommandHandlerWorkerThread.run
    (FTECommandHandlerWorkerThread.java:172)
      at java.lang.Thread.run(Thread.java:820)
      at com.ibm.wmqfte.thread.FTEThread.run(FTEThread.java:70)
    Caused by: com.ibm.wmqfte.statestore.FTEStateStoreException:
    BFGSS0020E: A sending transfer with the transfer ID
    <transfer_identifier>, is already present within the agent.
      at
    com.ibm.wmqfte.statestore.impl.FTEStateStorePersistence.putSende
    r(FTEStateStorePersistence.java:1165)
      at
    com.ibm.wmqfte.statestore.impl.FTEStateStoreImpl.newSenderTransf
    er(FTEStateStoreImpl.java:777)
      at
    com.ibm.wmqfte.cmdhandler.impl.FTECommandHandlerStateStoreImpl.p
    rocessFileTransfer(FTECommandHandlerStateStoreImpl.java:547)
    

Local fix

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects users of MQ Managed File Transfer who have
    queue resource monitors configured to trigger on individual
    messages, or complete message groups.
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    In MQ 9.1 LTS, the design of message-to-file transfers changed
    so that the messages were browsed while the managed transfer was
    taking place, and only removed from the source queue if the
    managed transfer was successful. Although this helped to prevent
    message loss, the design change meant that the "monitor retry
    for message-to-file transfers" functionality stopped working.
    
    To address this, the design of the "monitor retry for
    message-to-file transfers" functionality was changed so that
    queue resource monitors would perform the following steps if
    they detected either an individual message or message group that
    had been seen on a previous poll:
    
    - If there is already a managed transfer for this message or
    message group registered in the agent's state store then:
        - Ignore the message or message group.
    - Else:
        - If the value of the agent property monitorGroupRetryLimit
    is set to -1 then:
            - Submit a new managed transfer for the message or
    message group.
        - Else:
            - Check how managed transfers have been submitted for
    this message or message group.
            - If the number of managed transfers is greater than 1
    and less than the value of the agent property
    monitorGroupRetryLimit:
                - Submit a new managed transfer for the message or
    message group.
            - Else:
                -Ignore the message or message group.
            - End if
        - End if
    - End if
    
    This new design was first included in MQ 9.1.4 CD, and was
    ported to MQ 9.1. LTS under APAR IT29334.
    
    However, the new design did not work property if:
    
    - A resource monitor detected an individual message, or a
    complete message group, during one poll and submitted a managed
    transfer request to process it.
    - And the agent hasn't started processing that managed transfer
    by the time the next poll started.
    
    In this situation, there wasn't an in-progress managed transfer
    for the individual message or the complete message group when
    the second poll took place. This meant that the resource monitor
    would incorrectly assume that the managed transfer had finished
    and failed, and so would submit a second managed transfer
    request for that message or message group.
    
    When this occurred, one of three things could happen to the
    second managed transfer:
    
    1) If the first instance of the managed transfer was still
    running when the agent attempted to process the second managed
    transfer request, then the agent would generate an FDC
    containing the information shown below:
    
    ...
    Class:      com.ibm.wmqfte.cmdhandler.impl.MessageHandlerImpl
    Method:     externalMessageHandler
    Probe:      FFDC_001
    Cause:
    com.ibm.wmqfte.cmdhandler.FTECommandHandlerErrorException:
    BFGCH0005E: A problem occurred when registering a file transfer
    request.
    com.ibm.wmqfte.cmdhandler.FTECommandHandlerErrorException:
    BFGCH0005E: A problem occurred when registering a file transfer
    request.
    &#09;at
    com.ibm.wmqfte.cmdhandler.impl.FTECommandHandlerStateStoreImpl.p
    rocessFileTransfer(FTECommandHandlerStateStoreImpl.java:...)
    &#09;at
    com.ibm.wmqfte.cmdhandler.impl.FTECommandIntepreterFileTransfer.
    interpret(FTECommandIntepreterFileTransfer.java:...)
    &#09;at
    com.ibm.wmqfte.cmdhandler.impl.MessageHandlerImpl.externalMessag
    eHandler(MessageHandlerImpl.java:...)
    .......
    Caused by: com.ibm.wmqfte.statestore.FTEStateStoreException:
    BFGSS0020E: A sending transfer with the transfer ID
    transfer_identifier , is already present within the agent.
    ....
    
    and discarded the managed transfer request.
    
    2) If the first managed transfer request had completed
    successfully, then the agent would start processing the second
    managed transfer request only to find that the message was no
    longer on the source queue (it had been removed from the queue
    at the end of the first managed transfer):
    - If the source agent was running a version of the product that
    included the fix for APAR IT33189, then the managed transfer was
    marked as "Failed" with the supplementary information
    "BFGIO0414E: No messages exist on queue "LQ1@QM1"
    - If the source agent was running a version of the product that
    did not include the fix for APAR IT33189, then the managed
    transfer would be marked as "Successful" and the destination
    agent would create a zero-byte file.
    
    3) If the first managed transfer request had completed with a
    failure, then the agent would start processing the second
    managed transfer request and try to move the message again. This
    attempt would either succeed or fail, depending on whether the
    first managed transfer request failed due to a transient issue
    or a permanent one.
    

Problem conclusion

  • To resolve this issue, MQ Managed File Transfer agents have been
    updated to include a list of the transfer identifiers for
    managed transfer requests that have been submitted by resource
    monitors and have not yet been picked up an agent:
    
    - Whenever a resource monitor performs a poll and submits one or
    more managed transfers to an agent, the transfer identifiers for
    those managed transfers are added to the list of "pending
    monitor transfers".
    - When an agent picks up those managed transfer requests and
    registers them in its state store, the transfer identifiers for
    those managed transfers are removed from the "pending monitor
    transfers" list.
    
    If a queue resource monitor:
    
    - Finds a message or complete message group on the source queue,
    - And has seen that message or message group on a previous poll
    
    then it will check if there is managed transfer for that message
    or message group in both:
    
    - The list of "pending monitor transfers"
    - And the agent's state store.
    
    If there is an entry for the managed transfer in either the
    state store or the "pending monitor transfers" list, then the
    message or message group will be ignored.
    
    However, if there isn't an entry for the managed transfer in the
    state store and the list of "pending monitor transfers", then
    the monitor will check the value of the monitorGroupRetryLimit
    property and the number of managed transfers that have already
    been submitted for the message or message group in order to
    determine whether a new managed transfer request needs to be
    submitted.
    
    ---------------------------------------------------------------
    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.3
    
    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

    IT35322

  • Reported component name

    IBM MQ BASE MP

  • Reported component ID

    5724H7271

  • Reported release

    915

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2020-12-18

  • Closed date

    2021-03-18

  • Last modified date

    2021-03-23

  • 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 BASE MP

  • Fixed component ID

    5724H7271

Applicable component levels

[{"Line of Business":{"code":"LOB36","label":"IBM Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"915"}]

Document Information

Modified date:
24 March 2021