Community
Participate
Working Groups
For 3.4, even though people will likely keep on dl'ing the EPP packages. It is likely that they will try to browse the content of what is available on the ganymede update site which will cause the content.jar to be downloaded from the foundation server. To provide a sleek user experience I think that it may be good to ensure some minimal bandwidth for this file and also the artifacts.jar. To be precise we are talking about the following files http://download.eclipse.org/releases/ganymede/content.jar http://download.eclipse.org/releases/ganymede/artifacts.jar
I don't know much about web server administration, but knowing these files will be hit a lot and are static (rarely changed), you may be able to optimize for this to reduce disk and CPU load (such as keep them in memory).
First off, thanks for the head's up. No one usually tells me about these things until everything grinds to a halt and I'm stuck wondering why :) So, let me guess, those two URLs are hard-coded into p2? If so, why not use 'The Power Of Mirrors' and p2's ability to revert to download.eclipse.org if mirrors fail? http://www.eclipse.org/downloads/download.php?file=/releases/ganymede/content.jar&protocol=http&format=xml At any rate, I can't give specific files on one host any bandwidth priority over any other. However, we will have plenty of bandwidth in June, July and August for the Ganymede launch, so I wouldn't worry about it. However, I do assume that Eclipse caches those jar files on the local disk, and uses the http header 'If-Modified-Since' [1] to check the file for changes without re-fetching the file? If not, shall I open a bug? [1] See 14.25 of http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Yes, we use caching on the local client for content.jar and only download again if it changes. Since it will only change three times a year, most clients will rarely download it. We don't do the same caching currently for artifacts.jar, but this file is 47KB for all of Ganymede, and is only retrieved when someone performs an install operation, so further caching is likely not worth it. Using mirrors to downloading these jars would be interesting, but there is a chicken/egg problem because the mirror definition URL you mention lives inside the content.jar file. Ooops. In the future I could imagine having a separate small file that gives the mirror definition and then we could perform mirror downloads. If we did that, we would also need to enable signing and signature verification for these jars to ensure the mirror isn't tampering with it (I suppose a man in the middle attacker could do that even without mirrors). This is something we didn't get to for this release.
Great. You're caching the biggest jar (which is only about 1 MB) so, IMHO, this is a non-issue that likely doesn't warrant all the hassle of mirrors. Thanks for the head's up. I'm closing as worksforme as our systems shouldn't have any problems handling this. Of course, feel free to reopen June 25 if I'm proven wrong :)
Moving all these to Servers.
