Bugzilla – Full Text Bug Listing
| Summary: | Keep retrying install when disconnection occurs | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Vasilii Lukoyanov <lykoyanov> | ||||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | contact, Ed.Merks, lykoyanov, pascal | ||||||
| Version: | 3.4 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Vasilii Lukoyanov
Created attachment 113658 [details]
sceenshot of hanging update manager
Would you mind trying an add-on we created that uses Apache HTTP client for downloading updates? We believe it is much more responsive to timeout and connection problems than our current client. Your particular hardware/OS configuration is not one we have on hand so a quick test of this scenario with your setup would be much appreciated. http://wiki.eclipse.org/ECF_Apache_Httpclient-Based_Provider Ultimately this is a dup of bug 234916 but I'll leave this open for now to get your feedback. Could you also get stacktraces of the system when it is no longer responding. Thank you for response. I just tried the p/lugin you recommended. It seems more responsive to cancel button, but in general the problem still persists. Using new plugin when disconnection occurs it throws exception (see screenshot) but it doesn't retry update download (here I mean the files, that were being downloaded just at the moment of disconnection). Hence the whole update doesn't install properly. About stack traces. Now i can cancel the download and it doest hang anymore. Created attachment 113839 [details]
exception thrown on disconnection
Thanks for trying and reportig. As for the absence of retry, if I understand correctly you would want p2 to keep on trying to obtain the file / pause the all operation instead of failing. yes, i think that would be the most correct behavior. *** This bug has been marked as a duplicate of bug 267569 *** This is not a dup. One is about changing the code doing the actual mirroring, whereas the other one changes logic around MirrorSelection. >One is about changing the code doing the actual mirroring,
>whereas the other one changes logic around MirrorSelection.
Ok, which one of those is this bug about? I thought this bug was about adding retry logic when doing repository mirroring.
This about adding retry logic (probably with some sleep somewhere) when downloading artifacts during an installation. I can see the motivation for this, but currently it's not too bad that the user has to try the upgrade/install again if a disconnection occurs. If we keep trying during disconnection, we're going to need policies for how long to keep retrying, at what interval, etc, and how to control that policy for the various kinds of clients (UI, headless apps, etc). Some callers (such as automatic search for updates), may want to keep trying forever, whereas other callers it's more appropriate to just fail when a disconnection occurs rather than hanging indefinitely. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. The underlying frameworks have evolved a great deal, so I believe this issue is stale. |