Community
Participate
Working Groups
I was trying to update the Indigo aggregation build. I got an error while loading: http://download.eclipse.org/eclipse/updates/3.7.x/M20120111-0800 org.eclipse.equinox.p2.core.ProvisionException: No repository found at http://download.eclipse.org/eclipse/updates/3.7.x/M20120111-0800. org.eclipse.equinox.p2.core.ProvisionException: Artifact not found: http://download.eclipse.org/eclipse/updates/3.7.x/M20120111-0800/content.jar. I checked, and the update site is on the main Eclipse download server, and the content.jar is there and readable. Then I tried accessing this URL from my browser: http://download.eclipse.org/eclipse/updates/3.7.x/M20120111-0800/content.jar It redirected me automatically to: http://ftp.osuosl.org/pub/eclipse/eclipse/updates/3.7.x/M20120111-0800/content.jar and this failed because the mirror doesn't have the file. http://ftp.osuosl.org/pub/eclipse/eclipse/updates/3.7.x/ only lists: compositeArtifacts.jar 11-Jan-2012 15:26 450 compositeContent.jar 11-Jan-2012 15:26 447 I looked at this other mirror: http://eclipse.ialto.org/eclipse/updates/3.7.x/, and it also only lists: compositeArtifacts.jar 2012-Jan-11 16:01:39 450.00B JAR File compositeContent.jar 2012-Jan-11 16:01:39 447.00B JAR File So, download.eclipse.org apparently redirects requests to mirrors that don't have the requested file.
I've changed the regexp to redirect only /eclipse/updates/.*/R- Can you please try now?
It works now. Thank you.
I'm running into this issue again. I was trying to validate the Indigo aggregation model locally before I committed my changes. I got the following error: Artifact not found: http://download.eclipse.org/mylyn/drops/3.6.5/v20120214-0100/content.jar However, I can see the file is on disk on download.eclipse.org: /home/data/httpd/download.eclipse.org/mylyn/drops/3.6.5/v20120214-0100/content.jar But apparently, it automatically redirects me to a mirror which doesn't yet have the file — and maybe never will — and it fails: http://ftp.osuosl.org/pub/eclipse/mylyn/drops/3.6.5/v20120214-0100/content.jar This is preventing me from validating my changes locally. So, I have to commit blindly, with the risk of breaking the two hours long Indigo aggregation build for everyone.
The last time I checked, there was no p2.mirrorsURL property in any of the Mylyn repos, so I must force their repository to a specific mirror. Judging by the timestamp (v20120214-0100) I'd say that file is relatively new. I just tried downloading it about an hour ago, and it was there.
(In reply to comment #4) > I just tried downloading it about an hour ago, and it was there. That's strange. I still can't access this file from here (I always get an error 404). Have you tried downloading the content.jar file from outside the eclipse.org firewall?
Actually, I just crafted a nifty one-liner to examine the Indigo composite repo contents for the presence of the p2.mirrors property. for i in $(unzip -p /home/data/httpd/download.eclipse.org/releases/indigo/201109230900/content.jar | egrep "repository uri=.http://download.eclipse.org/(.*). " | sed 's/^.*<repository uri=.http:\/\/download.eclipse.org//' | awk -F\' {'print "/home/data/httpd/download.eclipse.org" $1 "/content"'}); do if [ -f "$i.jar" ]; then EXT="jar"; else EXT="xml"; fi; echo -n "$i.$EXT: "; unzip -p $i.$EXT | grep -c p2.mirrors ; done Here are the results.. am I understanding this right? 50 repos do not use mirrors, whereas 26 do? /home/data/httpd/download.eclipse.org/windowbuilder/WB/integration/3.7/content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/updates/releases//content.xml: 0 /home/data/httpd/download.eclipse.org/tm/updates/3.3/content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/updates/releases//content.xml: 0 /home/data/httpd/download.eclipse.org/modeling/emft/mwe/updates//content.xml: 0 /home/data/httpd/download.eclipse.org/tm/updates/3.3/content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/emft/mwe/updates//content.xml: 0 /home/data/httpd/download.eclipse.org/technology/emft/updates//content.xml: 0 /home/data/httpd/download.eclipse.org/technology/emft/updates//content.xml: 0 /home/data/httpd/download.eclipse.org/modeling/gmf/updates/releases//content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/gmf/updates/releases//content.jar: 1 /home/data/httpd/download.eclipse.org/mylyn/releases/3.6/content.xml: 0 /home/data/httpd/download.eclipse.org/birt/update-site/3.7/content.jar: 1 /home/data/httpd/download.eclipse.org/mylyn/releases/3.6/content.xml: 0 /home/data/httpd/download.eclipse.org/birt/update-site/3.7/content.jar: 1 /home/data/httpd/download.eclipse.org/datatools/updates/content.jar: 1 /home/data/httpd/download.eclipse.org/datatools/updates/content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/emft/updates//content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/emft/updates//content.jar: 1 /home/data/httpd/download.eclipse.org/stp/updates//content.xml: 0 /home/data/httpd/download.eclipse.org/stp/updates//content.xml: 0 /home/data/httpd/download.eclipse.org/tools/orbit/downloads/drops/R20100519200754/repository/content.xml: 0 /home/data/httpd/download.eclipse.org/tools/orbit/downloads/drops/R20100519200754/repository/content.xml: 0 /home/data/httpd/download.eclipse.org/technology/subversive/0.7/update-site//content.jar: 0 /home/data/httpd/download.eclipse.org/technology/subversive/0.7/update-site//content.jar: 0 /home/data/httpd/download.eclipse.org/releases/indigo/content.xml: 0 /home/data/httpd/download.eclipse.org/releases/indigo/content.xml: 0 /home/data/httpd/download.eclipse.org/technology/epp/updates/udc//content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/emf/updates//content.jar: 1 /home/data/httpd/download.eclipse.org/technology/epp/updates/udc//content.jar: 1 /home/data/httpd/download.eclipse.org/mat/1.1/update-site//content.jar: 0 /home/data/httpd/download.eclipse.org/modeling/emf/updates//content.jar: 1 /home/data/httpd/download.eclipse.org/mat/1.1/update-site//content.jar: 0 /home/data/httpd/download.eclipse.org/tools/gef/updates/releases/content.jar: 0 /home/data/httpd/download.eclipse.org/tools/gef/updates/releases/content.jar: 0 /home/data/httpd/download.eclipse.org/modeling/m2t/updates/releases//content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/m2t/updates/releases//content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/emft/eef/updates/0.7.1//content.xml: 0 /home/data/httpd/download.eclipse.org/modeling/emft/eef/updates/0.7.1//content.xml: 0 /home/data/httpd/download.eclipse.org/modeling/gmf/updates/milestones//content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/gmf/updates/milestones//content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/tmf/updates//content.xml: 0 /home/data/httpd/download.eclipse.org/modeling/tmf/updates//content.xml: 0 /home/data/httpd/download.eclipse.org/tools/orbit/downloads/drops/updateSite/content.xml: 0 /home/data/httpd/download.eclipse.org/tools/orbit/downloads/drops/updateSite/content.xml: 0 /home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/updates/milestones/0.8/content.xml: 0 /home/data/httpd/download.eclipse.org/rt/rap/1.3/tooling/content.jar: 0 /home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/updates/milestones/0.8/content.xml: 0 /home/data/httpd/download.eclipse.org/rt/rap/1.3/tooling/content.jar: 0 /home/data/httpd/download.eclipse.org/technology/actf/0.9/update-site//content.jar: 1 /home/data/httpd/download.eclipse.org/technology/actf/0.9/update-site//content.jar: 1 /home/data/httpd/download.eclipse.org/tools/ptp/updates/indigo/content.jar: 0 /home/data/httpd/download.eclipse.org/tools/ptp/updates/indigo/content.jar: 0 /home/data/httpd/download.eclipse.org/stp/updates/content.xml: 0 /home/data/httpd/download.eclipse.org/stp/updates/content.xml: 0 /home/data/httpd/download.eclipse.org/sequoyah/updates/2.0//content.jar: 0 /home/data/httpd/download.eclipse.org/sequoyah/updates/2.0//content.jar: 0 /home/data/httpd/download.eclipse.org/jwt/update-site/content.jar: 0 /home/data/httpd/download.eclipse.org/jwt/update-site/content.jar: 0 /home/data/httpd/download.eclipse.org/objectteams/updates/contrib/content.xml: 0 /home/data/httpd/download.eclipse.org/objectteams/updates/contrib/content.xml: 0 /home/data/httpd/download.eclipse.org/modeling/m2t/updates//content.jar: 1 /home/data/httpd/download.eclipse.org/modeling/m2t/updates//content.jar: 1 /home/data/httpd/download.eclipse.org/objectteams/updates/2.0/content.xml: 0 /home/data/httpd/download.eclipse.org/objectteams/updates/2.0/content.xml: 0 /home/data/httpd/download.eclipse.org/modeling/mdt/updates//content.jar: 1 /home/data/httpd/download.eclipse.org/tools/gef/updates/milestones//content.jar: 0 /home/data/httpd/download.eclipse.org/modeling/mdt/updates//content.jar: 1 /home/data/httpd/download.eclipse.org/tools/gef/updates/milestones//content.jar: 0 /home/data/httpd/download.eclipse.org/modeling/m2t/xpand/updates//content.xml: 0 /home/data/httpd/download.eclipse.org/modeling/m2t/xpand/updates//content.xml: 0 /home/data/httpd/download.eclipse.org/egit/updates/content.jar: 0 /home/data/httpd/download.eclipse.org/egit/updates/content.jar: 0 /home/data/httpd/download.eclipse.org/rt/rap/1.3/runtime/content.jar: 0 /home/data/httpd/download.eclipse.org/rt/rap/1.3/runtime/content.jar: 0 /home/data/httpd/download.eclipse.org/windowbuilder/WB/integration/3.7/content.jar: 1
actually, the p2.mirror attribute in a content.jar/xml file is a bit of a waste, it is not used. The one that matters is in the artifacts.jar/xml file. The results might not be much better, but they'd be more valid.
Thanks, David. Here's what I'm seeing: of the 24 "plain" (non-composite) repos listed, 13 use mirrors, 11 don't. /home/data/httpd/download.eclipse.org/birt/update-site/3.7/artifacts.xml: 1 /home/data/httpd/download.eclipse.org/datatools/updates/artifacts.jar: 1 /home/data/httpd/download.eclipse.org/egit/updates/artifacts.jar: 0 /home/data/httpd/download.eclipse.org/jwt/update-site/artifacts.jar: 0 /home/data/httpd/download.eclipse.org/mat/1.1/update-site//artifacts.jar: 0 /home/data/httpd/download.eclipse.org/modeling/emft/updates//artifacts.jar: 1 /home/data/httpd/download.eclipse.org/modeling/emf/updates//artifacts.jar: 1 /home/data/httpd/download.eclipse.org/modeling/gmf/updates/milestones//artifacts.jar: 1 /home/data/httpd/download.eclipse.org/modeling/gmf/updates/releases//artifacts.jar: 1 /home/data/httpd/download.eclipse.org/modeling/m2t/updates//artifacts.jar: 1 /home/data/httpd/download.eclipse.org/modeling/m2t/updates/releases//artifacts.jar: 1 /home/data/httpd/download.eclipse.org/modeling/mdt/papyrus/updates/milestones/0.8/artifacts.jar: 0 /home/data/httpd/download.eclipse.org/modeling/mdt/updates//artifacts.jar: 1 /home/data/httpd/download.eclipse.org/rt/rap/1.3/runtime/artifacts.jar: 0 /home/data/httpd/download.eclipse.org/rt/rap/1.3/tooling/artifacts.jar: 0 /home/data/httpd/download.eclipse.org/sequoyah/updates/2.0//artifacts.jar: 0 /home/data/httpd/download.eclipse.org/technology/actf/0.9/update-site//artifacts.jar: 1 /home/data/httpd/download.eclipse.org/technology/epp/updates/udc//artifacts.jar: 1 /home/data/httpd/download.eclipse.org/technology/subversive/0.7/update-site//artifacts.jar: 0 /home/data/httpd/download.eclipse.org/tm/updates/3.3/artifacts.jar: 1 /home/data/httpd/download.eclipse.org/tools/gef/updates/milestones//artifacts.jar: 0 /home/data/httpd/download.eclipse.org/tools/gef/updates/releases/artifacts.jar: 0 /home/data/httpd/download.eclipse.org/tools/ptp/updates/indigo/artifacts.jar: 0 /home/data/httpd/download.eclipse.org/windowbuilder/WB/integration/3.7/artifacts.jar: 1
(In reply to comment #8) > Thanks, David. Here's what I'm seeing: of the 24 "plain" (non-composite) repos > listed, 13 use mirrors, 11 don't. > And to be explicit, "composites" don't matter either, just the "plain" artifacts.jar/xml files do. So, the good news is the "main" repo at /releases/indigo uses them! Hopefully, that's where most end-users would "get" their updates are artifacts be mirrored from somewhere closer to them than eclipse.org. But, perhaps your logs say differently? People doing "builds" and "tests" probably use the project repos more directly, as in this case, where a test was desired before committing to the "common repo". FYI, just to cross reference, this is why I argue in bug 329923 that the "metadata files" should not be served from mirrors (just the artifacts, which p2 would handle, if p2.mirrorsurl attribute is used, as it should be).
Another observation (or question?) ... not sure how you are "finding" the 24 artifacts.jar/xml files mentioned in comment 8, but sounds like that's a small number, since there's like 50 projects participating in Indigo. And, I don't see "webtools" for example. Do you use same/similar one-liner as in comment 6? Cool one-liner by the way ... that should provide me a day or two of entertaining learning to figure out how it works :) Makes me miss the days of APL! :)
I'm using this one-liner to find them: for i in $(unzip -p /home/data/httpd/download.eclipse.org/releases/indigo/201109230900/content.jar | egrep "repository uri=.http://download.eclipse.org/(.*). " | sed 's/^.*<repository uri=.http:\/\/download.eclipse.org//' | awk -F\' {'print "/home/data/httpd/download.eclipse.org" $1 "/artifacts"'}); do if [ -f "$i.jar" ]; then EXT="jar"; CMD="unzip -p"; else EXT="xml"; CMD="cat"; fi; if [ -f "$i.$EXT" ]; then echo -n "$i.$EXT: "; $CMD $i.$EXT | grep -c p2.mirrors; fi; done | sort | uniq Some of them are not located on download.eclipse.org (they're on www) so I'm ignoring them. Also, some of them don't have an artifacts.jar/xml (they are composites) so I'm not "recursing" into them. Anyway, I do have a script which lists the most popular files downloaded from download.eclipse.org, and after the metadata files, the mylyn repos were in first place -- hence the reason I've redirected them explicitly.
I've documented another case, in bug 329923 ... guess one but is a duplicate of the other, but thought I'd cross-reference.
Do you mind if I highjack this bug? It originally was about the same (but worst case) problem discussed in bug 329923 [eh, funny, I just noticed that's a palindrome bug :) ] but since then, the discussion has grown more into the reasons this "direct, forced, in appropriate, re-direct mirroring is done in the fist place" ... namely, that some projects do not use the p2.mirrorURL attribute in their artifacts.jar/xml and thus too many requests for artifacts (jars, bundles) come back directly to "download.eclipse.org" instead of being offloaded to the 50 or 70 mirrors that make up part of the eclipse infrastructure, so to speak. Thus, I'd like to make this a cross-project bug, and discuss why so many do not use p2.mirrorURL and what we can do about it. According to the brief, informal statistics collected by Denis, roughly 50 percent do not. Those that do not have one, even old artifact.jar/xml files, could be fixed! I'm not sure if the effort should be a massive "fixup" of all artifact.jar/xml files ... or to focus on those that have an abnormally large number of jars being requested directly from download.eclipse.org, if such statistics could be easily obtained by analyzing logs?
I should note, there are a few other reasons why requests might come back to download.eclipse.org, even if the artifacts.xml file does contain the p2.mirrorsURL attribute: a) the attribute value might be wrong b) too many people might be using -Declipse.p2.mirrors=false to purposely avoid mirrors. So ... I am just saying that "too many requests back to downloads" might be caused by other things ... but, seems like having no p2.mirrorsURL attributes would be the first thing to fix?
Hi, I verified the "p2.mirrorsURL" for MoDisco and EMF Facet, and fixed two that were wrong. Here is a one-liner that I used to quickly find missing or wrong p2.mirrorsURL: find . -type f -name 'artifacts.jar' -or -name 'artifacts.xml' | while read i; do echo "$i"; if [[ "$i" =~ .*/artifacts.jar ]]; then echo " "$(unzip -p "$i"|grep "p2.mirrorsURL"); else echo " "$(cat "$i"|grep "p2.mirrorsURL"); fi; done
(In reply to comment #13) > > Thus, I'd like to make this a cross-project bug, and discuss why so many do not > use p2.mirrorURL and what we can do about it. > Maybe it's just me, but I did not realize we had to configure p2.mirrorURL ourselves until now. I assumed mirroring is something done by the foundation and projects don't get to choose if their binaries are served from download.eclipse.org directly or from mirrors. I think a reminder on crossplatform list with instructions how to configure p2.mirrorURL and how to fix existing artifacts.xml will be useful.
(In reply to comment #13) > Do you mind if I highjack this bug? Be my guest :) Like Igor mentioned, I suspect many projects don't even know about the mirrorsURL.
(In reply to comment #16) > (In reply to comment #13) > > > > Thus, I'd like to make this a cross-project bug, and discuss why so many do not > > use p2.mirrorURL and what we can do about it. > > > > Maybe it's just me, but I did not realize we had to configure p2.mirrorURL > ourselves until now. I assumed mirroring is something done by the foundation > and projects don't get to choose if their binaries are served from > download.eclipse.org directly or from mirrors. I think a reminder on > crossplatform list with instructions how to configure p2.mirrorURL and how to > fix existing artifacts.xml will be useful. +1. Instructions would be helpful. And if the involves manually editing the xml files, it's not likely to happen on a regular basis.
I agree, some improved tooling would be helpful. There are some "outlines" of some tools in bug 310132 which I happen to know can be modified to programatically update the p2.mirrorsURL property ... now if I can just track those down and find some documentation ... :) Actions I've taken thus far: I have "beefed up" the section in IT Documentation wiki to stress everyone should do this, see http://wiki.eclipse.org/IT_Infrastructure_Doc#Enable_mirrors_.2F_use_mirrorsURL_for_my_p2_repo.3F Plus, I have added more detail (and corrections) to the main p2.mirrorsURL wiki, such as added a new section: http://wiki.eclipse.org/Equinox/p2/p2.mirrorsURL#Who_should_add.3F Plus, added it to the already-too-wordy "Simultaneous Release Requirements" document (even though, it is not technically a "Simultaneous Release Requirement" ... just to help spread the word that it is required for all p2 repositories on Eclipse Foundation infrastructure. http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Provide_optimized_p2_repository_.28partially_tested.29 [If not obvious, I am stretching my authority for me to say it is required for all p2 repositories on Eclipse Foundation infrastructure ... but, we'll see who complains that it is not really required and they won't do it :) ] Thank you very much, Igor, sincerely, for your comment 16. Sometimes we forget what seems like "common knowledge" is only common knowledge to those of us that have been doing it for a long time. I think next steps here are: - See if we can find or provide some modest tooling (even if "unofficial"). - See if we can better assess the problem cases ... I hate to ask our overworked webmasters to do more work, but if there's some easy log-report you could generate that would show "excessive requests" coming back to download.eclipse.org, that might help focus who needs to fix what. I understand it is hard to assess "excessive requests" (maybe impossible?) ... but, just a suggestion. - Other suggestions welcome.
Actually, we regularly check what comes out of download.eclipse.org ... for our own sanity.
(In reply to comment #20) > Actually, we regularly check what comes out of download.eclipse.org ... for our > own sanity. Well, what was thinking more about, say, a weekly report of "*jar and *jar.pack.gz" requests coming back to download.eclipse (except for the metatdata files) so maybe the "most problematic cases" could be addressed (first, or soonest). There are, after all, thousands of artifact.jar/xml files on "downloads" and some of them really do not _need_ the p2.mirrorsURL (such as, if part of an integration build repo, or something, which wouldn't be mirrored anyway, and/or some may be requested so seldom that they do not matter in any practical way). But ... a top ten list would allow focus. and some history of "how bad the problem is" over time. Of course, if you'd prefer just to eye-ball it on your own and take action or talk to the projects when something seemed "odd" that's perfectly fine by me. I just wanted to be sure I explained what I meant.
> Well, what was thinking more about, say, a weekly report of "*jar and > *jar.pack.gz" requests coming back to download.eclipse (except for the > metatdata files) so maybe the "most problematic cases" could be addressed > (first, or soonest). We have web stats available via portal.eclipse.org > Eclipse Projects > [tools] for all Committers > Web Server Statistics. I am not sure how useful these can be https://dev.eclipse.org/committers/webstats/download.eclipse.org/usage_201202.php Interestingly, almost half the requests are 404 Not Found as p2 looks for a bunch of files that are not there, and probably never will be (sounds like a potential enhancement to p2) Equally interesting is how download.e.o's traffic almost doubled starting Feb 24.
(In reply to comment #22) > https://dev.eclipse.org/committers/webstats/download.eclipse.org/usage_201202.php > WOW, I see what you mean now ... 300 of the top 400 downloads are metadata files! Of the remaining, I did notice (and track down) one odd thing with "windowbuilder" ... and opened bug 372927 to track ... has to do with them (inappropritatly) using "integration" URL, which of course are not mirrored by design. A few other oddities not tracked down ... wpt patches should not be downloaded 200 K times per month for example ... someone's doing something crazy there, I suspect ... might want to see how many IP addresses that request comes from ... if 3 or 5, then someone (probably in the company I work for) is doing something crazy ... if its coming from dozens? hundreds? of IP addresses then someone is probably still doing something crazy, but we might want to consider mirroring them? Its expected these would only be need by 6 or 12 people ... but, someone may be routinely getting them "because they are there" or something. Don't know. Conclusion, I think such reports can be helpful ... but pretty tedious to work through and track down root issue. Maybe I'll check back after after a few weeks in March. :)
> Interestingly, almost half the requests are 404 Not Found as p2 looks for a > bunch of files that are not there David, the top 20 404's I'm seeing are _all_ for p2.index files: 246262 /releases/indigo/p2.index 221161 /releases/indigo/201202240900/p2.index 204910 /technology/epp/packages/indigo/SR2/p2.index 204465 /releases/indigo/201109230900/p2.index 204026 /technology/epp/packages/indigo/SR1/p2.index 203246 /technology/epp/packages/indigo/R/p2.index 199183 /releases/indigo/201106220900/p2.index 171166 /eclipse/updates/3.7/R-3.7-201106131736/p2.index 169069 /eclipse/updates/3.7/R-3.7.1-201109091335/p2.index 166483 /eclipse/updates/3.7/R-3.7.2-201202080800/p2.index 166256 /eclipse/updates/3.7/p2.index 118848 /mylyn/drops/3.6.5/v20120215-0100/p2.index 102787 /releases/helios/p2.index 96464 /eclipse/updates/3.7/categories/p2.index 95817 /releases/helios/201006230900/p2.index 95250 /technology/epp/packages/helios/p2.index 94385 /releases/helios/201009240900/p2.index 94215 /technology/epp/packages/helios/R/p2.index 93984 /technology/epp/packages/helios/SR1/p2.index 93625 /releases/helios/201102250900/p2.index Should we be creating p2.index files for our repos? From the docs: "As a provider of a repository, it does not help you directly, but it helps your users to get a better experience and also slightly reduce the number of hits your server will be subject to." http://wiki.eclipse.org/Equinox/p2/p2_index
(In reply to comment #24) > > Should we be creating p2.index files for our repos? Yes, this is discussed in bug 347448. I know the (latest) version of b3 aggregator produces them automatically ... not sure why the "normal" p2 publisher (or, other p2 publishers) do not ... or, maybe they do? But, IMHO, it's a bit of odd design and file hacked in to p2 to fix one (rare) problem, poorly documented, and then inadvertently "required" for all p2 sites. I definitely plan to introduce these into Juno ... I feel a little less confident about retro-fitting this to older sites. But, suspect discussion on the topic should continue in the original bug 347448.
(In reply to comment #23) > (In reply to comment #22) > > A few other oddities not tracked down ... wpt patches should not be downloaded > 200 K times per month for example ... someone's doing something crazy there, I > suspect ... Not a too much of a mystery after all. Carl Anderson reminded me we did provide a patch for that version of WTP, so I think there really are just that many users of that "old" version of WTP (Ganymede?) that check for updates. I wonder if having the preference "automatically check for updates" causes a lot of aggressive "checking" and re-fetching data even when there has been no changes? But, that's off-topic of this bug.
(In reply to comment #19) > I agree, some improved tooling would be helpful. There are some "outlines" of > some tools in bug 310132 which I happen to know can be modified to > programatically update the p2.mirrorsURL property ... now if I can just track > those down and find some documentation ... :) Ok, found it (just kidding, just wrote it :) See http://wiki.eclipse.org/WTP/Releng/Tools/addRepoProperties Let me know fi anyone finds it useful ... or, build a better one. > I think next steps here are: > > - See if we can find or provide some modest tooling (even if "unofficial"). > Ok, another, final step, I'll send msg to cross-project about this, and p2.index, then consider this bug closed. If anyone (e.g. webmasters) see "problem cases" I'd suggest specific bugs be opened on those projects ... or, here in cross-project is fine too if hard to pinpoint or needs widespread awareness.
Ok, I've sent note ... updated all the docs I can think of ... so, will close this one as "fixed". As mentioned, If anyone sees "problem cases" I'd suggest specific bugs be opened on those projects. Feel free to ask questions on cross-project list if anyone has "how to" questions. I'll leave bug 329923 open for now and encourage people to make note there of "failure cases" when they encounter them.
