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

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.
  	at
  com.ibm.wmqfte.cmdhandler.impl.FTECommandHandlerStateStoreImpl.p
  rocessFileTransfer(FTECommandHandlerStateStoreImpl.java:...)
  	at
  com.ibm.wmqfte.cmdhandler.impl.FTECommandIntepreterFileTransfer.
  interpret(FTECommandIntepreterFileTransfer.java:...)
  	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 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