Community
Participate
Working Groups
When the eclipse update server is overloaded, the update process is very slow. We need to make sure we don't add overhead, and also try to improve the lookup and download process to alleviate the problem. For example, one should have enough info in site.xml so that no extra feature jar downloads are needed to just present the results.
Overhead is made by many feature jars being downloaded during search phase. Every jar is about 24kbytes, where only 4kbytes is relevant info and other 20k are image and license files. Simple example is check for update of EMF 2.2.0 Eclipse fetches http://download.eclipse.org/tools/emf/updates/site.xml And after that it downloads 1.5Mb of 63 jars with total about 1.6Mbytes just to tell me there is no updates available for EMF. I do not know exact sheme how updater works, but from my perspective these shouldn't be downloaded just because component numbers in filenames are older than installed on my system. I've got org.eclipse.xsd_2.2.0 org.eclipse.emf_2.2.0 org.eclipse.emf.ecore.sdo_2.2.0 ... And fetched filenames list is attached. Proposals to improve update mirrors speed and save traffic: 1. Change Updater component to take into account version info of feature .jar filenames in site.xml files 2. Do not include image/license info in feature.jar files or put that info (feature.xml) first in compressed .jar file. This can enable partial .jar downloads (fetch first 4k and if feature.xml is fully included in this chunk proceed to other .jar). 3. Add other necessary information into site.xml to avoid all available .jar downloads (to find out that information it would be nice to have a reference describing current update process, but I haven't found any yet)
Created attachment 27740 [details] .jars fetched for EMF 2.2.0 update
>3. Add other necessary information into site.xml to avoid all available .jar >downloads (to find out that information it would be nice to have a reference >describing current update process, but I haven't found any yet) I agree. The dfault Site.xml implementation should be self contained. Fetching all the feature Jars is non-sense.
*** This bug has been marked as a duplicate of 144876 ***
