Am 04/07/2012 07:49 PM, schrieb Dennis E. Hamilton:
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
OK, do you have any suggestions different to my initial post in this thread?
-----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>
[ ... ]
Yes, thats correct.
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>
Where else do you see important values that need to be changed?
Why is it dangerous? Every web application has a kind of property
management. Just change the value here instead of delivering changed
code on many different places.
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
