> Date: Mon, 1 Nov 2004 15:15:19 +0100 (CET)
> From: Daniel Stenberg <daniel-curl_at_haxx.se>
> On Thu, 28 Oct 2004, Rich Gray wrote:
>
>> I like doing retries in terms of determining how long the operation
>> has to succeed. Keep trying until that limit is reached. It would
>> seem that the outer limit is already available in the form of the
>> -m/--max-time <seconds> parameter. The only other requirement then
>> is to keep from beating things up if one is experiencing quick
>> failures. A delay parameter is needed.
>
> I've currently considered --max-time as a timeout for each individual
> attempt, and if it times out I thought of it as reason to retry.
>
> Should I perhaps instead make --max-time the maximum allowed time
> including retries? If not, should I have a separate --retry-max-time ?

I suppose one does need the operational timeout. There may be cases
where a connection 'evaporates'. If the protocol is at a phase where
curl is waiting on a reply, it will wait forever. One does need to give
up and start the whole thing over. So I guess --max-time should be per
attempt. --retry-max-time would then be a way to set an outer time limit.

Another thought on retries is the retry interval. I'd make the case
that instead of a simple inter-retry interval, one might set an interval
based on the start time of each attempt. --retry-interval could
specify that a retry would be attempted no more often than the given
number of seconds.

curl ... --max-time 60 --retry-interval 30 --retry-max-time 600 ...

would specify an operation where retries will be attempted for up
to 10 minutes at intervals of no closer than 30 seconds. Each attempt
will be allowed 60 second to succede. If an attempt gets a quick
failure, it would wait out the *remainder* of the 30 seconds before
retrying, assuming --retry-max-time is not exceded when the next retry
is to start. If an attmempt goes beyond the retry-interval (out to
--max-time) a retry would commence immediately, again assuming
--retry-max-time has not been reached. These settings would produce
10-20 retries over 10-11 minutes. (The 11 minute case would occur if
a retry were started just before --retry-max-time was reached and
went for --max-time seconds.)

I think this has nicer properties than trying to figure out number
of times in the face of failures which may be immediate or very long.

Of course, I still think this is doable in shell too!

Cheers!
Rich
Received on 2004-11-02