Comments in-line. I think it would be good to step back and agree on what problem that is being solved and how should failure cases and intervention work. Then it can be determined whether candidate code addresses the problem or not.
- Dennis -----Original Message----- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Saturday, April 07, 2012 10:13 To: ooo-dev@incubator.apache.org Subject: Re: [DL LOGIC] How to choose a mirror when more than 1 is available? [ ... ] > 2. The requests are distributed randomly based on the allocation > percentages to the systems whether or not they are available. Yes, but only when they are available. If not they get no requests. > 3. For any mirror system that receives a turn when it is not > available, the backup system is used. The non-available system won't get a request. It's directly forwarded to another one. <orcnote> The current logic does not try a different one if the random choice is in-range for a non-available mirror system. It always goes to the backup. There is no retry. You can see that by running the sample page a couple of times. </orcnote> [ ... ] > My only other observations are > > a. It should be easier to identify the systems and their > allocations and to update that information in the script. All values are (or should be) in the "globalvars.js" file. So, only in one location there are changes necessary. <orcnote> globalvars.js is not a one-stop shopping place for adjusting the allocations and availabilities with a simple change. It's a tremendous warehouse of global settings of all kinds. globalvars.js is a dangerous thing to touch in order to change allocations and/or workaround mirror unavailability. </orcnote> > b. If availability is to be determined dynamically, it is > probably better to check availability only after determining > that the system has been selected by the random procedure. > Also, if availability is configured manually, there is probably > some shared dataset that should hold the availability information > (and the allocations?) so the script does not have to be touched > and outages/re-allocations can be done quickly and reliably. No, it's not done dynamically (yet). We have to know if a system is down. Then we can disable it in the "globalvars.js" file. BTW: Sorry, if the quoted text is now messed-up. It was extremly difficult to answer as there was no line wrapping. Marcus > -----Original Message----- > From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] > Sent: Saturday, April 07, 2012 07:13 > To: ooo-dev@incubator.apache.org > Subject: [DL LOGIC] How to choose a mirror when more than 1 is available? > > For our new release we will have a changed set of conditions: > > - new central mirror hosts for redirecting download requests > - therefore also a new set of mirror server that host our builds > - new set of supported platforms and languages > - slighty changed file name schema > > To get this all under one hat, we have to improve the download logic > that is currently done by JavaScript. > > To fulfill the first condition the download requests have to be split-up > to more than 1 central mirror redirector. > > Here is a suggestion for choosing when (by random number) to redirect to > which mirror: > > http://www.openoffice.org/download/test/index_new_dl.html > > Test results: > - to make debugging easier I've included some screen output and comments > - I've tested it locally with different combinations of active/inactive > hosts and it works well > - the fallback method works well, too > - I've tested different percent values as ratio, but not yet for the > 2nd case > > What do you think? > > Marcus
