On Mon, Jul 2, 2012 at 4:00 PM, James Antill <ja...@fedoraproject.org> wrote: > I was hoping Zdenek would reply, as I know even less about urlgrabbing > now than I ever did!:) Saying that ... > > > "retries" is documented as (in yum): > > retries: Set the number of times any attempt to retrieve a > file > should retry before returning an error. Setting this to `0' > makes yum try forever. Default is `10'.
Fair enough, but this is untrue in the current code. At this point, yum does not /ever/ retry a urlgrab from a given mirror. The current urlgrabber callback unconditionally raises an error. It was suggested to me that this was done deliberately to get yum to advance to the next mirror on errors. In the process the retries setting became effectively ignored. > So I'm pretty sure we don't want to change that to mean something like > "if you have 50 mirrors (usual in Fedora) and retries=10, we'll retry a > file 500 times" ... which is what I _think_ this patch set does. If the current code did not prevent urlgrabber from retrying, then the number of potential retries per grab would also be (retries setting) * (# of mirrors). The difference is: my patch interlaces those retries across the mirror list. Since the current retries documentation has not been correct for some time, I think it would be reasonable to adopt the current patch and add a note in the doc about retry behavior and mirrors. Consider the case where #mirrors > (retries setting). Should yum give up after $retries mirrors in that case? If a strict per-url retries counter is what folks really want, I'd be happy to rework the patch. Note that there are plenty of repos with a small number of mirrors, or none. The singleton repo is an important case and one where we currently seem to have zero network failure tolerance. Also, at the point we're retrying, the alternative is failure. > I'm also tempted to NAK/ignore the 503 problem in general, unless we > can deal with Retry-After headers the whole things seems like a guessing > game on if we really should immediately retry (Yes, for Fedora it is, > but I did not think this was universal -- in fact the opposite). The most recent patch retries all failures, not just 503s, though 503s were what caused me to look into this. In the latest patch I tried to keep things simple, but I can modify it to honor retry-after headers. In that case we'd probably want to add a new config option, something like max_retry_wait. Note that even in the current patch the retry might not be immediate. Yum will try all the mirrors before retrying any of them. Unless all the mirrors fail, there will be no retries of earlier failing mirrors. _______________________________________________ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel
