https://bugzilla.novell.com/show_bug.cgi?id=411409
User poeml@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=411409#c3
--- Comment #3 from Peter Poeml
im not an http expert, but wasnt there an http replycode that said something like server busy for now, or please revisit at a later time again. meaning to delay the http fetching of the metadata file.
The above fix pretty much avoids the need for this from the start. I am rather sure that the rest is neglectable. I'd rather spend time on fixing the bigger problems with Factory and BS next. :)
if i understand the whole mirror concept properly, this metadata comes from only one source: your opensuse download server. everbody gets their metadata from there and only gets redirected (if applicable) filewise to mirrors and such.
Yes, that's right.
so during the time period of updating the metadata file on this one masterserver, the httpd itself could actually block the delivering of the currently being updated metadta file with a http-reply that the visting client (yast, zypper, whatever) should revisit in like 10seconds or half a minute or whatever the intervals would fit.
Yes, that would be possible. I suggested something similar in the past for Factory updates. Since we control the client pretty much, this could be implemented. However, for the update tree we also need to take into account that there are other clients than libzypp which access the tree, so it shouldn't disturb them. People sometimes have self-written scripts that check for updates and such stuff. A 5xx code as such wouldn't be handled by them (neither would it by libzypp in its present form). For Factory it would be fine I assume.
something like that? maybe that would be the safest way to handle the metadataupdates.
503 service unavailable? and maybe implement some delay to re-try/re-fetch the metadata again when 503 is being given.
I believe this is best to be handled at the application level. After all, libzypp might talk to an entire separate server (a mirror, a local mirror, or a proxy cache) where it could encounter a similar situation, without provision for return codes with special meaning (if we did that). If libzypp handles it on the application level (in an "oops, something's wrong, let's just check this again" manner), it could work around these edge cases under various circumstances. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.