Bugzilla – Full Text Bug Listing
| Summary: | When update site has redirect for some feature, this feature is not shown in Update Manager. | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Alexei Goncharov <alexei.goncharov> |
| Component: | p2 | Assignee: | Simon Kaegi <simon_kaegi> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | alexei.goncharov, eclipsebugs, github, pascal |
| Version: | 3.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Alexei Goncharov
Still no response? Simon, could you please investigate and advise? Thx Alexei, could you provide the URL of the site showing the problem and maybe also attach the site.xml in question. Thx I believe you're using the update site located here: http://download.eclipse.org/technology/subversive/0.7/update-site/site.xml When you provide an absolute url like for your primary feature its retrieval is no longer handled by p2's mirroring code and furthermore p2 is unaware that the call will be directed to a potentially unreliable source. At an implementation level p2 will try retrieving content from this url twice before deciding the content url is bad and as you've pointed out, in cases where the content is not yet fully synched the retrieval will fail and result in an update site that is missing the feature. If a relative feature url is provided p2 will go through and try to retrieve the feature from every mirror before giving up. This provides us with some robustness in the event that for example a mirror server is down. In a nutshell, I would strongly suggest you use a relative url to get the regular p2 mirroring support. Your current approach is going to be unreliable so long as the mirrors are not fully synched or donw for repair. Unfortunately this also means that I don't have a good way for you to collect download stats. (In reply to comment #3) > I believe you're using the update site located here: > http://download.eclipse.org/technology/subversive/0.7/update-site/site.xml > > When you provide an absolute url like for your primary feature its retrieval is > no longer handled by p2's mirroring code and furthermore p2 is unaware that the > call will be directed to a potentially unreliable source. At an implementation > level p2 will try retrieving content from this url twice before deciding the > content url is bad and as you've pointed out, in cases where the content is not > yet fully synched the retrieval will fail and result in an update site that is > missing the feature. > > If a relative feature url is provided p2 will go through and try to retrieve > the feature from every mirror before giving up. This provides us with some > robustness in the event that for example a mirror server is down. > > In a nutshell, I would strongly suggest you use a relative url to get the > regular p2 mirroring support. Your current approach is going to be unreliable > so long as the mirrors are not fully synched or donw for repair. Unfortunately > this also means that I don't have a good way for you to collect download stats. > Hi, Simon. So, as far as I understood, this behavior seems to be normal for you. But, correct me if I'm wrong, but I do think that some concrete implementation of the update-manager is not an excuse. I do really think that a lot of Eclipse projects use the same way of collecting the downloading statistics for them, cause this script was provided much earlier than p2 was implemented and this way of collecting the stats it the way, offered by Eclipse Foundation. I think that the bug should stay opened and its severity should not be decreased. So if you can do nothing with this, as from your message it is supposed that I'm right, please try to have some talk with Eclipse web-masters to provide, maybe, another way of collecting the stats, which would be friendly to p2. Best regards, Alexei Goncharov (Subversive Team). Alexei, I noticed that you haven't run the site optimizer on your update site. See: http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_metadata_generator.html This would likely help your sites usability in that the feature metadata for your "download counter" feature would be pre-generated. This means that the feature would always show up in the p2 UI as p2 won't need to go fetch it. You would still continue to have the problem of an unreliable download of the feature though. (In reply to comment #3) > When you provide an absolute url like for your primary feature its retrieval is > no longer handled by p2's mirroring code and furthermore p2 is unaware that the > call will be directed to a potentially unreliable source. At an implementation > level p2 will try retrieving content from this url twice before deciding the > content url is bad and as you've pointed out, in cases where the content is not > yet fully synched the retrieval will fail and result in an update site that is > missing the feature. I've just thought about one thing. Maybe it is applicable in such case also check the main download area after failure? Is it possible to do so? If not, why? Or shall I speak to Denis to ask him to provide the option for the URL to be redirected ONLY to main download area. Denis has now opened a bug for a feature to support download stats. I'm going to dup this now to it so we have a concrete case. *** This bug has been marked as a duplicate of bug 251907 *** |