Bugzilla – Full Text Bug Listing
| Summary: | Double-download of Feature and Plugin JARs during successful update with standalone API | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Alex Sanielevici <alexsani> |
| Component: | Update (deprecated - use Eclipse>Equinox>p2) | Assignee: | Platform-Update-Inbox <platform-update-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | caniszczyk, jdmiles, lfrenzel, Mike_Wilson, pam_tobias, steven.wasleski |
| Version: | 3.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
I was looking at the install handler calls today and I am seeing an indication of the same thing. However it wasn't limited to standalone commands. I am seeing it happen using the update GUI. It seems to me that executing handler calls multiple times is not an innocent behavior. This might cause unintended side effects. Has anyone checked this bug or related bug 84103 recently? There was some performance work that went into Update Manager recenetly. Dejan, is there any chance that the recent performance work fixed these problems too? Branko should know the details. Branko? i am inspecting this. The issues here is not double downloading but double or even triple connecting to the update site for the same resource. The offender here is caching system in update. It checks its consistency using method UpdateManagerUtils.isSameTimestamp which opens connection to server using http get method (this is what apache logs) to check for time stamp of the required file. However, although this is less of a problem then downloading whole files twice it is still very serious problem since opening connections to servers is very expensive. Am I correct to assume that this will not be fixed in 3.2? What is the outlook for a fix in 3.2.1? Cannot be fixed without reworking the entire logic. Checking file timestamps before downloading is part of the overall design. There are ideas to introduce a notion of a state so that the timestamp can be checked once only for the duration of the session, but this is not something to try in a point release. Dejan is right we played with the notion of session at one point for this release. But this means we have to re-write whole caching system and then we could centralize caching which is now distributed through out update. New centralized cache should probably cash files not objects. This should be done in future if update stays as it is. |
The symptoms described here are similar to those of 84103, but this is not a duplicate. The Feature JAR and Plugin JARs are fetched from the HTTP server exactly twice during a successful update operation triggered using the standalone API's UpdateCommand class, with any feature (for which update is available) given as parameter. Sample output from HTTP access log during a successful update: 127.0.0.1 - - [01/Aug/2005:13:58:37 - 0400] "GET /update/TestUpdate/features/Test_Feature_1.5.4.jar HTTP/1.1" 200 599 127.0.0.1 - - [01/Aug/2005:13:58:37 - 0400] "GET /update/TestUpdate/features/Test_Feature_1.5.4.jar HTTP/1.1" 200 599 127.0.0.1 - - [01/Aug/2005:13:58:37 - 0400] "GET /update/TestUpdate/plugins/com.test.plugin_1.5.4.jar HTTP/1.1" 200 391756 127.0.0.1 - - [01/Aug/2005:13:58:38 - 0400] "GET /update/TestUpdate/plugins/com.test.plugin_1.5.4.jar HTTP/1.1" 200 391756 My initial analysis, if it helps: From stepping through the debugger while following the access log with tail -f, I've found that for each update found by the update search, OperationFactory’s createInstallOperation() is called, which fetches the feature JAR for the first time. These install operations are collected into a BatchInstallOperation and then executed. During the execution, Feature.install() calls FeaturePackagedContentProvider.getFeatureEntryArchiveReferences(), which calls asLocalReference() and results in a re-downloading the feature JAR. Perhaps this can be avoided if the file were to be placed in the local cache, which this method checks with a call to Utilities.lookupLocalFile(key); As for the plugin JAR getting retrieved twice: the first time is Feature.install() -> getPluginEntryArchiveReferences() -> asLocalReference() resulting in a download. Then, in the loop where the files contained in the plugin JAR are stored, the first iteration is what *seems* to result in a re- download of the plugin JAR. I haven't been able to pinpoint why, so it may be something in another thread doing this. for (int j = 0; j < references.length; j++) { setMonitorTaskName( subMonitor, msg + references[j].getIdentifier()); pluginConsumer.store(references[j], subMonitor); }