| Re: [cross-project-issues-dev] List of files on Eclipse Mirror servers |
|
Ø
If there are resources available to work on this, it would be much better if download.eclipse.org served as central gateway to both the primary download
server and the archive. And, potentially, mirrors ! I think this has been discussed before (can’t find the exact reference now), but having to serve artifacts.jar (400K) and content.jar (> 2MB !) from a single
server looks like a bad bottleneck to me. For me, sitting in Europe, performing a “check for updates” is still ridiculously slow with Eclipse. Installing something from the train repository is OK once
I have chosen what to install …. But building the list to choose from is annoyingly slow even when there is no train release (typically > 2 minutes, see also
bug 347403 [1]). The workaround redirecting all master traffic to OSUOSL has caused issues in the past (bug 329923 [2]). Composite repositories have small master files – that would seem like a good chance using the composite only from the central server, but then allowing to mirror
metadata files from the children when timestamps are OK (or, pull in child repos from a different server like archive.eclipse.org etc). Or has this been implemented by now and I’m not up-to-date with the latest ? Martin [1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=347403 [2]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=329923 From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of Konstantin Komissarchik One of the problems with the archival process is handling of p2 repositories which do not go through the mirror selection script. http://wiki.eclipse.org/IT_Infrastructure_Doc#Move_files_to_archive.eclipse.org.3F Currently, only the mirror selection script is able to delegate to archive.eclipse.org, so auto-archiving would break those repositories. If there are resources available to work on this, it would be much better if download.eclipse.org served as central gateway to both the primary download server
and the archive. Then one can implement all sort of archiving policies without involving projects or affecting end users referencing these URLs… You can auto-archive based on age, you can auto-archive based on demand, heck you can even pick a goal for how
much to mirror and have a heuristic that shuffles between primary and archive to meet that goal. - Konstantin From:
cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
On Behalf Of Wayne Beaton Does it make sense to consider moving files that are old--say three or more years old--to the archive server automatically? To help you clean up older builds and files from the Eclipse download server, I've compiled a list of files that are actually sync'ed to our mirrors.
-- |