Community
Participate
Working Groups
Right now a mirror is either 'good' or 'bad'. We will continue to try and fetch an artifact from a 'good' mirror, even if there is a problem with that particular artifact. A problem with a single artifact doesn't make the mirror 'bad'. This was first seen in bug 327256. We need the ability to capture the mirror XYZ is fine, however, there is a problem with artifact foo at that location, and we should stop trying this mirror for that artifact.
I think that what's needed is a scoring mechanism where the scores are influenced by several things. - Download Speed - Missing artifacts - % up time I can think of a few other improvements as well. Manual control: I would like one preference where I could list my favorite mirrors in order of priority and another where I could disable mirrors that are known culprits. Ideally this would be a user preference and not a workspace preference. Multiple parallel downloads attempts for large files: I've often encountered mirrors that give me below 20Kb/s and that becomes a real pain when the file several MB in size. One way to avoid that would be if p2 could contact more than one mirror for each file and then discard the slower ones. Detection of bad mirrorsURL: There have been times when everything just stalls because a repository publisher did a mistake with the mirrorsURL. When using the repository, p2 attempts the download from a lot of places (all mirrors?) and it takes a very long time to discover that none of them have the file.
May not be directly related, or relevant, but worth noting ... I believe the current "list of mirrors" is returned from eclipse.org in a "recommended order", where that order is based on geographic proximity. (see bug 99412) Primarily that's because geographic proximity is correlated with download speed ... but also some would say its "good for the internet" not to be traversing the world if not necessary. So ... just wanted to remind everyone of this little tidbit ... not sure it will be very useful or relevant ... but wanted to capture it, just in case.
*** Bug 326107 has been marked as a duplicate of this bug. ***
