Community
Participate
Working Groups
Created attachment 174874 [details] Thread dump of hanging eclipse 4.0 Build ID: http://download.eclipse.org/e4/sdk/drops/I20100720-2028/ on WinXP SP3 1. Launch eclipse.exe 2. Help > Install new Software - Repo: http://download.eclipse.org/dsdp/tm/updates/3.2 - Pick Main Features > TM Terminal - Next, Install Dialog hangs in "calculating requirements and dependencies" since 20 minutes. Thread dump attached. The "TM Terminal" has minimal dependencies and can actually run on eRCP for the most part, so I had picked this as a first test...
I couldn't see anything in the thread dump that looked like Eclipse 4.0 could make a difference. Could this just be a connection issue, or a bug in p2?
Eric and Bogdan both reported hanging problems yesterday while trying to install SWT Spy. I had a brief hang in my workstation (not at the UI level, just that the job wasn't progressing), but after cancelling and going through the dialog again it proceeded smoothly.
Well, Eclipse 3.6 was ridiculously slow too installing this feature, but succeeded after approx 4 minutes whereas 4.0 was still hanging after 20 minutes. On the 3.6 Stream, it looks like it's trying to download a ridiculously large amount of data from ridiculously slow servers - given that this is a bundle with minimal dependencies all of which should be satisfied by the core Workbench (except for one optional dependency on a serial line lib, which is not satisfiable in the context of Eclipse). On the 4.0 Stream, some additional problem seems to be there. As an end user, I'm pretty much blocked by this, and it's also making things a lot harder for early adopters who want to try out their stuff and need their downstream dependencies installed.
I can understand your frustration (and you are right about this affecting others when testing) but without any hint as to what we can do on the e4 side to fix this, what can we do? John, could someone from the p2 team investigate this?
Did you by chance had a message box hidden behind the update dialog? If you see that again, could you alt-tab to another application and alt-tab back to Eclipse, and/or try to move the update dialog? (I've seen this hapenning once or twice on both 3.x and e4, but never was able to reproduce.)
I checked, and there is no dialog in the back. What I find noteworthy is that in the Progress area (lower right of the parent window behind the install dialog), it looks like there are multiple attempts to get http://download.eclipse.org/downloads/e4/updates/4.0/I20100709-1350/content.jar and related content.jar from many other I-builds. It looks like some repo is built into my configuration which tries getting all past I-builds (which does not make any sense IMO). Remy's suggestion to cancel and re-try does not help. The issue is 100% reproducable also after quit & restart. I'm also attaching my .log but I don't think this helps since its messages seem all to come from the workbench shutdown, and not the install dialog.
Created attachment 174889 [details] .log from my workspace.
(In reply to comment #6) > it looks like there are multiple attempts to > get > > http://download.eclipse.org/downloads/e4/updates/4.0/I20100709-1350/content.jar I believe I was also seeing a lot of e4/updates hammer-age.
bug 320309 ... I'll clean up the update site as soon as the current build finishes. That should reduce the child repos in both http://download.eclipse.org/e4/updates/2010 and .../eclipse/updates/4.0 PW
I've shrunk our composite repo from 21 to 6 sites, and made sure they all have .jar files. Martin, has that helped the flickering you see in the progress? (If you use mirrors it might take a while to mirror) PW
Created attachment 174960 [details] .log after successful install The Repo cleanup fixed the main problem, and I could install the Terminal bundle. It was still surprisingly slow; I cannot tell how slow though, since after a minute or two I left it running for a while and when I returnd it had gone past the verification step. The log still contains a couple of errors (attached), like "Provisioning Exception ... OK" and this: No repository found at http://download.eclipse.org/e4/updates/2010/I20100721-1145.
Paul completely cleaned out the p2 repositories before the final build, so that should improve performance greatly. I think there is nothing more to do on this bug from the e4 side. If it is still too slow we should move this to p2 as an issue with scalability when interacting with very large composite repositories.
I'm fine closing this concrete issue and opening something new under p2. From a high level (end user's point of view) my concern is this: I had explicitly specified a repo, and selected a feature all of which features were resolveable by what is installed. I did not expect p2 to consult any other repositories, especially not the large composite one that led to hanging Eclipse. User Story could be: As an Eclipse user, I want to install additional software from a known repository fast, without consulting any additional repositories or updating any locally existing software unless it is necessary (due to missing dependencies). "Install new" and "Update existing" should be two workflows which can be run separately, whereas today it looks likes you cannot have A without B. I think this also fits in with similar behavior I've seen in the past, where my laptop was off the network and I wanted to install CDT from a local archived repo but p2 was slow because it tried to access the (non-accessible) Helios repo. Is there an existing bug / enhancement request for this?
Works on I20110617-1015; took a few minutes (2 minutes?). I'll close this as the e4 part has been done, see comment 10. (In reply to comment #13) > "Install new" and "Update existing" should be two workflows which can be run > separately, whereas today it looks likes you cannot have A without B. That sounds very reasonable to me. However, from my limited understanding of how p2 works, it is indeed true that "A" and "B" are the same. I might be wrong about it; the best course of action would be to, indeed, open a more general enhancement request for p2.
