What happens if an MFT agent becomes disconnected from its agent queue manager?
Paul_Titheridge
Published on 28/09/2018
In an IBM MQ Managed File Transfer (MFT) topology, every agent has an agent queue manager that it connects to. This queue manager hosts the various system queues that the agent needs in order to perform managed transfers.
Agents connect to the queue manager using either the BINDINGS or CLIENT transport when they start up. In this blog post, we’ll look at what happens if an agent loses the connection to the agent queue manager and becomes disconnected.
Agents that connect using the BINDINGS transport.
Agents that are located on the same physical system as their agent queue manager can connect to it using the BINDINGS transport.
Figure 1: If an agent and its queue manager are located on the same system, the agent can connect using the BINDINGS transport.In this configuration, if the agent queue manager becomes unavailable, then the agent will stop and write the following message to its event log (output0.log):
BFGAG0170W: The agent has ended because the queue manager is unavailable. The agent will be restarted when the queue manager becomes available.
When this happens, the agent’s Process Controller will write the messages:
BFGPC0052W: Process has ended with return code 75 because the queue manager is unavailable. The process will be restarted when the queue manager becomes available. BFGPC0029W: The process controller was unable to connect to the application's queue manager '<queue manager name>'. The MQ reason code returned is : <reason code>. The process controller will try to connect to the queue manager again after 30 seconds. The queue manager retry period is specified by the application property 'agentQMgrRetryInterval'
to its event log (pcevent0.log), and then monitor the queue manager at regular intervals (as specified by the agent property agentQMgrRetryInterval), to see when it comes back up again.
When the Process Controller finds that the queue manager is running, it will automatically restart the agent. It will also log the message:
BFGPC0034I: The process controller has established a bindings transport mode connection to queue manager '<queue manager name>'. The application will be started.
to its event log.
Agents that connect using the CLIENT transport.
If an agent is running on a different system to its agent queue manager, then it will connect to the queue manager using the CLIENT transport.
Figure 2: If an agent and its queue manager are on different systems, the agent connects using the CLIENT transport.When using the CLIENT transport, if the agent queue manager is unavailable for some reason (such as a network outage) then the agent will log the message:
BFGAG0048W: A client transport mode connection cannot be established to queue manager '<queue manager name>' with connection name '<hostname>(<port>)' and using channel '<channel>'. The reason code is <reason code>. The agent will try the operation again every 30 seconds.
to it’s event log (output0.log), suspend any in-flight managed transfers, and then try to reconnect to the queue manager every 30 seconds. When the agent can contact the queue manager again, it writes the message:
BFGAG0057I: The agent has established a client transport mode connection to queue manager '<queue manager name>' with connection name '<hostname>(<port>)' and channel '<channel>'. The agent is ready to be used for transfers.
to the event log, and then restarts the in-flight managed transfers that were suspended earlier.
As always, I hope this helps! If you have any questions on this, let me know and I’ll be happy to answer them.