When retry is set to n, should n+1 requests be sent to a Url?

[Guest mrdavidlaing]

Here is the current behaviour when a Uri is throwing 500’s, and retry count is set to 3:

26/01/2011 10:19:38 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Dispatched #1 : https://ciapiprepr*******extest9.co.uk/TradingApi/session'>https://ciapiprepr*******extest9.co.uk/TradingApi/session'>https://ciapiprepr*******extest9.co.uk/TradingApi/session'>https://ciapiprepr*******extest9.co.uk/TradingApi/session'>https://ciapiprepr*******extest9.co.uk/TradingApi/session'>https://ciapiprepr*******extest9.co.uk/TradingApi/session'>https://ciapiprepr*******extest9.co.uk/TradingApi/session'>https://ciapiprepr*******extest9.co.uk/TradingApi/session
26/01/2011 10:19:44 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Recieved #1 : https://ciapiprepr*******extest9.co.uk/TradingApi/session  
26/01/2011 10:19:44 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Dispatched #2 : https://ciapiprepr*******extest9.co.uk/TradingApi/session
26/01/2011 10:19:49 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Recieved #2 : https://ciapiprepr*******extest9.co.uk/TradingApi/session
26/01/2011 10:19:49 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Dispatched #3 : https://ciapiprepr*******extest9.co.uk/TradingApi/session
26/01/2011 10:19:54 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Recieved #3 : https://ciapiprepr*******extest9.co.uk/TradingApi/session
26/01/2011 10:19:54 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Dispatched #4 : https://ciapiprepr*******extest9.co.uk/TradingApi/session
26/01/2011 10:19:59 [DEBUG] CityIndex.JsonClient.ThrottedRequestQueue - Recieved #4 : https://ciapiprepr*******extest9.co.uk/TradingApi/session

CityIndex.JsonClient.ApiException : The remote server returned an error: (500) Internal Server Error.
retried 3 times
   .... snip ...

This behaviour caught me by surprise; since I was expecting the Url to be hit a maximum of 3 times.

Of course, it does also make sense to think that it tried once, and then retried 3 times; resulting in 4 total requests.

What do you think is the correct behaviour?

[steffen.opel 10]

While I see the potential for confusion, I think retries should indeed be taken literally and the current behavior is what should be expected.

Specifically, one might want to not retry something as well, i.e. just perform a request once and fail thereafter – this would have to be communicated as retry=1 otherwise and pose more confusion I think. Additionally there are related parameters sometimes as well, e.g. retry-delay, which wouldn’t make sense then.

If you’d prefer to specify the absolute number of requests, the parameter should be called tries instead, see retry (plural retries): Another attempt. in contrast to try (plural tries): An attempt.

Samples in the wild:

• cURL

--retry

If a transient error is returned when curl tries to perform a transfer,
it will retry this number of times before giving up. Setting the number
to 0 makes curl do no retries (which is the default).

• Wget

--tries=number

Set number of retries to number. Specify 0 or ‘inf’ for infinite retrying.
The default is to retry 20 times, with the exception of fatal errors like
“connection refused” or “not found” (404), which are not retried.

So for Wget one indeed has to specify the absolute number of requests (confusingly called ‘retries’ in the explanation) just like you expected, the parameter itself is calledtries though to communicate this.

[Guest mrdavidlaing]

While I see the potential for confusion, I think retries should indeed be taken literally and the current behavior is what should be expected.

Specifically, one might want to not retry something as well, i.e. just perform a request once and fail thereafter – this would have to be communicated as retry=1 otherwise and pose more confusion I think. Additionally there are related parameters sometimes as well, e.g. retry-delay, which wouldn’t make sense then.

If you’d prefer to specify the absolute number of requests, the parameter should be called tries instead, see retry (plural retries): Another attempt. in contrast to try (plural tries): An attempt.

Samples in the wild:

• cURL

--retry

 

If a transient error is returned when curl tries to perform a transfer,

it will retry this number of times before giving up. Setting the number

to 0 makes curl do no retries (which is the default).

• Wget

--tries=number

 

Set number of retries to number. Specify 0 or ‘inf’ for infinite retrying.

The default is to retry 20 times, with the exception of fatal errors like

“connection refused” or “not found” (404), which are not retried.

So for Wget one indeed has to specify the absolute number of requests (confusingly called ‘retries’ in the explanation) just like you expected, the parameter itself is calledtries though to communicate this.

Your point about how related params like “retry-delay” don’t make sense unless the original request isn’t considered part of the retry count is the clincher for me.