[Bug debuginfod/27531] Support retry of failed downloads

[sergiodj at sergiodj dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=27531

--- Comment #3 from Sergio Durigan Junior <sergiodj at sergiodj dot net> ---
(In reply to Frank Ch. Eigler from comment #1)
> Can you collect more information about the nature of the timeouts and
> what diagnostics if any libcurl/debuginfod-client returned?  The default
> timeout imposed by the debuginfod-client code is 90s to start returning
> file content, as governed by the $DEBUGINFOD_TIMEOUT environment variable.
> Would these folks like us to retry *beyond* that timeout?

First of all: yes, I can try to collect more info from them.  I've just emailed
one of the guys who brought this to my attention, and asked him if he can
provide more info and leave a comment here.

With that out of the way, I think it's worth mentioning that the retry idea did
not come from the reports I've received.  It is something that I figured would
be nice to have in order to mitigate the issues.

We are talking about two distinct (albeit related) things here: having a big
timeout does not necessarily mean that the download will succeeded, therefore
having the possibility of retrying makes a lot of sense.

> Or is the timeout at some earlier stage?  We'd need the diagnostics or
> packet trace or something like that.

I understand the intention to address the timeout problem, but there are things
out of debuginfod's control here.  One of the emails I received was from a
person who lives in China and therefore has to cope with their sub-optimal
international links.  As far as I understood from what they explained, a
connection between China and Europe is prone to suffer from the instability
that was reported.

-- 
You are receiving this mail because:
You are on the CC list for the bug.