Bugzilla – Full Text Bug Listing
| Summary: | Failing to try mirrors when processing steps reports an error | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Benno Baumgartner <benno.baumgartner> | ||||||||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | P3 | CC: | daniel_megert, jeffmcaffer, pascal, stepper, tjwatson | ||||||||||
| Version: | unspecified | Flags: | jeffmcaffer:
review+
tjwatson: review+ dj.houghton: review+ john.arthorne: review+ pascal: review+ |
||||||||||
| Target Milestone: | 3.4 RC4 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Benno Baumgartner
Benno, I don't clearly understand the steps you went through. Benno, I'm a bit confused by the steps. Is the problem coming from the fact that once the installation has failed with p2, then even the attempt at installing from the old UM fails as well? I think that even if the installation has failed you should be able to restart it and eventually get it to succeed. Btw I can now install successfully from the site you mentioned. Lowering down the severity. (In reply to comment #1) > Benno, I don't clearly understand the steps you went through. > Benno, I'm a bit confused by the steps. All I wan to say with my steps is, that I'm not able to install mylyn with the new update manager (and I've tried that for several hours, see all the bugs I've filed), but it works with the old update manager. But, if I first try it with p2, then go back to the old update manager, then the old one seems to be also broken, which is a blocker for me. Of course as soon as I'm able to install mylyn with p2 this bug will not be a blocker anymore (and I will try that in RC2;-) But I still think that p2 should not influence the old update manager in any way. But this might not be possible, I don't know the implementation details. > Is the problem coming from the fact that once the installation has failed with > p2, then even the attempt at installing from the old UM fails as well? Yes, this is why I marked the bug as blocker. (In reply to comment #3) > > Is the problem coming from the fact that once the installation has failed with > > p2, then even the attempt at installing from the old UM fails as well? > > Yes, this is why I marked the bug as blocker. This is still the case in I20080521-2000 and also bug 233201 is not fix. So I don't understand why you've changed the severity of this bug. Because many other ppl have been able to install mylyn and other things so I think that your issue is very specific and probably related to bug 233201. (In reply to comment #5) > Because many other ppl have been able to install mylyn and other things so I > think that your issue is very specific and probably related to bug 233201. I'm sorry pascal, but I'm still not able to install mylyn in I20080605-1800, after fix for bug 233201 I get an error: 'An error occurred while collecting items to be installed Problems downloading artifact: osgi.bundle,org.eclipse.mylyn.trac.core,2.3.2.v20080402-2100. Downloaded stream not a valid archive. Check the server.' I don't need to check the server (which server btw?), there is nothing I can do on the server side. This bug is still a blocker for me, for anybody else in the zuerich lab, and I guess for a lot of users trapped behind 'smart' proxies. We will not be able to install anything from the ganymede update site with p2. I think we should not ignore this. If p2 can not select another mirror automatically then at least let me choose one. benno, did you authenticate to the BSO firewall? Can you see the resources that get downloaded? What do they contain? The new code will automaticlaly go through all known mirrors to try and find the thing you are looking for. So it would appear that somehow your mirror list is not complete. p2 should try and fail (assuming you are not authenticated) and then move on to other mirrors. We did run into some cases recently where the other mirrors also did not have the resources. In that case the artifacts really were not available to you. Given the random nature of the contnet returned by smart proxies and the like it is very difficult for p2 to offer the user the opportunity to login or otherwise authenticate. If you have suggestions on who this could work, we'd be very happy to consider them. As a debugging approach, can you try running with -debug <location of options file> and put the following in the options file? org.eclipse.equinox.p2.core/debug=true org.eclipse.equinox.p2.core/artifacts/mirrors=true This will report in the console which mirrors are being selected, which fail, ... You will see entryies from a number of worker threads. First they will select a mirror and then report on the quality of the mirror. There will be two numbers reported. The first is the number of failures seen on that mirror. The second is the download rate (in bytes). -1 there indicates a failure I think. Please give this a shot and then attached the console output to this bug. Created attachment 103959 [details]
debug log
It fails with message:
An error occurred while collecting items to be installed
Problems downloading artifact: osgi.bundle,org.eclipse.mylyn.context.ui,2.3.2.v20080402-2100.
Downloaded stream not a valid archive. Check the server.
(In reply to comment #7) > benno, did you authenticate to the BSO firewall? Don't know how to do that. > Can you see the resources > that get downloaded? > What do they contain? org.eclipse.mylyn.context.ui is not in the plugins folder. Pascal said to try to install it again, and it worked, it did donwload context.ui and after a restart mylyn was up and running. > Given the random nature of the contnet returned by smart proxies and the like > it is very difficult for p2 to offer the user the opportunity to login or > otherwise authenticate. If you have suggestions on who this could work, we'd > be very happy to consider them. My suggestion is not trying to be smart, just let the user choose a mirror (I i.e. know that the switch mirror works) Looking at the trace here is what I noticed. We have two threads that ends up picking the raleigh mirror (worker-3 and worker-6). However the download in worker-3 does not fail (see trace below) and therefore we do not retry the download, whereas the download on worker-6 eventually does fail and we end up retrying the artifact. [p2] Fri Jun 06 16:27:25 CEST 2008 - [Worker-3] Selected mirror for artifact http://download.eclipse.org/tools/mylyn/update/e3.4/plugins/org.eclipse.mylyn.context.ui_2.3.2.v20080402-2100.jar: Mirror(http://fullmoon.rtp.raleigh.ibm.com/tools/mylyn/update/e3.4/,0,-1) [p2] Fri Jun 06 16:27:26 CEST 2008 - [Worker-3] Updated mirror Mirror(http://fullmoon.rtp.raleigh.ibm.com/tools/mylyn/update/e3.4/,0,1164) [p2] Fri Jun 06 16:27:25 CEST 2008 - [Worker-6] Selected mirror for artifact http://download.eclipse.org/tools/mylyn/update/e3.4/plugins/org.eclipse.mylyn.help.ui_2.3.2.v20080402-2100.jar: Mirror(http://fullmoon.rtp.raleigh.ibm.com/tools/mylyn/update/e3.4/,0,-1) [p2] Fri Jun 06 16:27:46 CEST 2008 - [Worker-6] Updated mirror Mirror(http://fullmoon.rtp.raleigh.ibm.com/tools/mylyn/update/e3.4/,1,1164) Created attachment 103989 [details]
Patch fixing the problem
Created attachment 103991 [details]
cleaned up patch
The original patch had some extra stuff. I cleaned that up and added a few comments to the code. Please review this patch
The capsule summary of the problem is that we fail to consult additional mirrors when a download fails because of an error detected by the processing steps. I walked through the patch with Jeff. It looks reasonable to me and the issue is severe if we don't fix this. Created attachment 104029 [details]
Updated patch
This update is from a review with DJ/John/Pascal. Two changes:
- The previous patch didn't check for null on the "mirrors" field in all cases. This would NPE if mirroring was disabled
- The previous patch changed the code path from the folder-based descriptor case. Before the patch, the folder-based case was handled first and the mirroring code was never entered. With the patch, the folder-based case would now do mirror selection, and mirror updating based on the result. This updated patch reverts to putting the folder-based descriptor case at the very beginning of the protected downloadArtifact method so that code path is no longer affected by this fix.
One final change in this patch was to replace status.matches(IStatus.OK | IStatus.INFO | IStatus.WARNING) with status.matches(IStatus.INFO | IStatus.WARNING) Since IStatus.OK == 0 this is a no-op change, but the previous code was misleading because it looked like it was matching OK, WARNING, or INFO. In fact it was only checking INFO or WARNING. Tagged and bagged. verified in I20080609-1311 Thanks for the hard work and for making this possible. *** Bug 236631 has been marked as a duplicate of this bug. *** |