Before declaring the repository as “offline” and waiting for the timeout that was specified, Artifactory is performing retries (10 retries with the extended timeout). During these 10 retries, the interval between the retries is “slowly increasing” up to the configured assumed offline period and if the retries also fail then it will fall back to the parameter that was specified in the “Assumed offline period”. In cases of an unstable network, if the parameter was simply respected as is and the algorithm was ignored, the repository would be put in an “offline” mode indefinitely, a scenario that we would like to avoid.
The following scenario should demonstrate the above - Consider having a network with intermittent connectivity issues (in which there is a disconnection every 2 seconds) and the repository retry timeout is set to 10 seconds. In this case, the repository will be offline indefinitely since every 10th second Artifactory will perform the check and will fail again. Instead, with the retry mechanism, before giving up to the predefined parameter, we will be able to keep the repository online.
The following scenario should demonstrate the above - Consider having a network with intermittent connectivity issues (in which there is a disconnection every 2 seconds) and the repository retry timeout is set to 10 seconds. In this case, the repository will be offline indefinitely since every 10th second Artifactory will perform the check and will fail again. Instead, with the retry mechanism, before giving up to the predefined parameter, we will be able to keep the repository online.