-- An end user had been reviewing the statistics for a particular transfer. the custoemr noticed that the statistics always displayed 0 (zero) retries. The same issue was seen when a transfer to a trading partner failed due to an invalid password, the retres still displayed 0 retries. This may not be what the end user might expect

-- Gateway is working as designed. There are basically two types of connection retries: one for a network connection retry attempt, and one for transfer retry attempt. However, as far as the Gateway log is concerned it only sees the string "retry connection (1/10.....9/10)"

On the "Options" tab of the Remote Site in Gateway, you will see a setting called "Maximum number of connection retries before time limit. By default, this setting is set to 10. This setting actually has a dual setting.

Case One
========

In the case where a password for the user id you are trying to connect with has changed on your trading partner's side, Gateway won't be able to make the connection,

1. The password changes on the trading partner's side.
2. Gateway cannot establish the connection.
3. Gateway reports an error in the Gateway log: connection in requestor mode refused: reason="25, Invalid password"
4. As Gateway cannot establish the connection, the transfer cannot start.
5. Gateway will attempt to retry the connection x number of times, where x represents the number of connection retries you define in the site. If you set 10 connection retries, you will see Gateway attempt 10 retries. In each case, the time for each retry attempt doubles:

1/10 - 10 secs, 2/10 - 20 secs, 3/10 - 40 secs, 4/10 - 80 secs, 5/10 - 160 secs, 6/10 - 320 secs, 7/10 - 640 secs, 8/10 - 1280 secs. Connection retries 9/10 and 10/10 were both 1800 secs.

After the tenth connection retry, Gateway will recycle the connection retries and set them back to 0/10. Gateway will then retry the connections again until such time that the transfer (in the ToBegin state) is manually cancelled. If the transfer is not cancelled, Gateway will retry the connections indefinitely. In this case, the statistics never get updated from 0, as the connection is never established, and the transfer is never started.

Case Two
=========

In the second case, Gateway had been able to establish the connection and the transfer had already begun. In testing carried out by support, a 1GB file transfer was started from my FTP client (Gateway) to a second Gateway (FTP server) over SFTP.

1. The transfer was started.
2. The transfer was initially in a ToBegin state, but after a few moments automatically changed to an InProcess state (yellow).
3. During the tranfer I stopped the Gateway on my virtual machine (the FTP server).
4. The transfer on my FTP client changed from inProcess to ToBegin.
5. I restarted gateway on the virtual machine (server).
6. The transfer restarted when the next retry attempt was made.
7. The Statistic count for the transfer changed from 0 to 1
8. After the 10th stopping and restarting of gateway, my FTP client machine (gateway) automatically cancelled the transfer, as it had hit the maximum number of retries. At this point the transfer is canclled.

Notes
=====
Gateway is working as designed, and the statistics are working correctly. There are some settings that can be used in the first case to cancle the transfer if the max retry limit is hit, which will stop gateway from wasting resources. In the second case, the transfer is automatically cancelled.

--Resolution: Gateway could not make the connection and could not start the stransfer. The snippet of the Gateway log reviewed by Support demonstrated that an invalid password was being sent. The transfer would have sat in a ToBegin state until the password was rectified on the trading partner's side. The connection was re-attempted, and this time it succeeded. The transfer started and completed, resulting in an Ended state (green). The statistic was correctly showing 0, as the connection was not established for 8 hours.