Bugzilla – Full Text Bug Listing
| Summary: | Eclipse hangs at "initializing java tooling" | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | Jason Sholl <jsholl> | ||||||
| Component: | jst.j2ee | Assignee: | Jason Sholl <jsholl> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Chuck Bridgham <cbridgha> | ||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | alois.geith, bokowski, ccc, david.matejcek, david_williams, eclipse, eclipse, fbricon, forrest.humphrey, hbrands, hej, ittay.dror, javalexchen, jmestres, jochenstiepel, jtk499, kaloyan, luca.preziati, master.of.flex, nederveen, philippe_mulet, pub.cog, remy.suen, Sebastian.Dietrich, shr31223, snjezana.peco, stryker, thebravoman, thepcmechanic, townsendmerino | ||||||
| Version: | 3.2 | Flags: | cbridgha:
review+
|
||||||
| Target Milestone: | 3.2.3 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 241343 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jason Sholl
Here's the link to the deadlock: https://bugs.eclipse.org/bugs/attachment.cgi?id=180872 The fix needs to be made on the Worker-3 thread. Everything up to and including the call to VirtualComponent.getRawReferences(VirtualComponent.java:401) is OK. The problem is getRawReferences() should never be calling into JDT. The whole point of this method was to ensure such calls were never made (to avoid deadlocks such as these). *** Bug 327831 has been marked as a duplicate of this bug. *** I vote for a Hotfix as soon as it's fixed. Created attachment 180983 [details]
patch
This patch fixes the getRawReferences() so it does not call into IVirtualComponent.exists(). The Javadoc is updated. This method is only used by the DependencyGraphImpl and was added during 3.2 specifically for the DependencyGraphImpl to avoid these sorts of deadlocks. Moreover, it is in an internal class so adopters should not be using this method, which it is why this subtle change is safe and appropriate.
(In reply to comment #5) > Created an attachment (id=180983) [details] > patch > > This patch fixes the getRawReferences() so it does not call into > IVirtualComponent.exists(). The Javadoc is updated. This method is only used > by the DependencyGraphImpl and was added during 3.2 specifically for the > DependencyGraphImpl to avoid these sorts of deadlocks. Moreover, it is in an > internal class so adopters should not be using this method, which it is why > this subtle change is safe and appropriate. can you please provide as well the compiled .class file for the patch - would be much easier to apply/test the patch in my environment... I haven't tested this yet, but I strongly believe this is a good fix. I remember at one point testing what happens if you have one environment with a CustomReferenceType, add that reference to a project, and then load it into a workspace without the plugins needed to dereference a CustomReferenceType. If I remember correctly, the items were filtered out when references were returned, which isn't a problem in itself, except than any further changes to the reference list would save the list *without* the missing refernece type. So if the project was committed somewhere, an older user or a user in a different environment would be removing the unfound/DNE reference even if the other environment user still depended on it being there. I can't really think of an example where this becomes troublesome to users, but, I can say that it would be unexpected that a user trying to add a new resource-mapping for example might also remove a missing reference type and muck over other committers on the project. There might be affects here on the add / remove dependency page, though, if a user attempts to remove a reference type which does not exist or is not found. In an effort to assist Fred and Sebastion and give them SOMETHING to test, I imported the proper plugin into my workspace, changed the file, and exported the plugin as a jar. I then moved it into my workspace, and moved the previous file out. So I replaced org.eclipse.wst.common.modulecore_1.2.3.v201008242000.jar with org.eclipse.wst.common.modulecore_1.2.3.v201010192000.jar (uses patch) Unfortunately, when re-loading the workbench, wst.common.modulecore (and most of jee) refused to load. Does anyone have any advice on making a quick test jar which can actually run in the workbench? Thanks. > I imported the proper plugin into my workspace,
This should read that I placed the jar inside my build's eclipse/plugins folder, not that I imported it into my workspace.
Created attachment 181205 [details]
Runtime patch for 322
This is a test runtime feature patch built specifically for WTP 3.2.2. It will not work on any other WTP versions. To install it extract the zip file to the dropins folder of your WTP install. By default this will be eclipse/dropins. You will need to restart the workbench after extracting the zip. To confirm it is properly picked up (aside from there no longer being deadlocks :) ) check the version of org.eclipse.wst.common.modulecore (it should be 1.2.3.v201010191306) through Help -> About Eclipse SDK -> Installation Details -> Plugins Tab.
Thanks in advance for testing this. Please let us know if this fixes your deadlock scenarios so we can safely roll this into WTP 3.2.3.
After testing, if you wish to remove the test patch, simply delete the files you extract and restart WTP. The patch works perfectly. My corrupt workspaces now start normally. Great stuff Jason, thanks a lot! +1000 for the hotfix now :-D approved thanks works for me - thanks a lot! Code checked into 32_M and HEAD streams for WTP 3.2.3 and 3.3 respectively. My team has decided that this issue is severe enough that it could require a patch build on an update site. It affects many different products that use WTP. David: Any help on the process here? Thanks. (In reply to comment #16) > My team has decided that this issue is severe enough that it could require a > patch build on an update site. It affects many different products that use WTP. > > David: Any help on the process here? Thanks. I assume you mean on a WTP update site? (though we try to call those software repository sites, now :). Or did you just want to know some technical tips so you can create your own site for your own products. If the later, I can point you to http://wiki.eclipse.org/WTP/Build/WTP_Patches_for_Release_3x_streams which is probably a little out of date already (but I can help, and bring it up to date, if that's what you meant). If you meant the former, the first step is to get your project lead to agree, and for them to raise it up for PMC Review. (This is in Common Tools, right?, so that'd be Carl). The PMC Review is part of our conventions simply because it does become part of our persistent code repo, could effect other products, etc., so deserves wide-spread awareness and review. If you did mean the former, I would be willing to help with mechanics. We do patch builds on a regular basis for adopters, which do not become part of the projects persistent code repo, so this would simply be a twist on that work. (In fact, probably should have a separate bug and branch for that ... perhaps we'll call it R3_2_2_updates so there is a clear distinction.) Just to cross-reference, a similar request has been made for bug 321602 (which was approved by PMC in 10/7 status meeting). The JBoss team (and I believe the maven team as well, as judging by fred Bricon) request this to be added to a WTP 3.2 maintenance update site to be available to all users searching for updates via the standard mechanisms. *** Bug 329974 has been marked as a duplicate of this bug. *** *** Bug 330065 has been marked as a duplicate of this bug. *** I also vote for a "hot fix" as the patch seems to fix startup issues we have observed in combination with the m2eclipse plugin. (Please let me know if I should attach the Eclipse log for those startup issues.) *** Bug 331356 has been marked as a duplicate of this bug. *** +1 for a hot fix. This bug affects many developers, they probably don't know the cause and so they delete there complete workspace/.metadata files! This is a really serious bug! (In reply to comment #23) > +1 for a hot fix. The "hot fix" is what's attached to this bug. Unfortunately, there's no easy way to rollout a hot fix, that users would get 'automatically'. It varies, or depends on, how users installed things to begin with, but our impression is that most users would still have to "hear about" where the hotfix was available, in a software repository, and then navigate there to specifically install that hotfix. That seems about the same as them navigating to this bug and installing what's attached here. Some bugs are open to improve the update ability in the future, such as bug 329973, but until then, seems little benefit to putting in a repository. If I've misunderstood, please let me know. David, I have to disagree. If you can't roll out a patch, what's the point of http://wiki.eclipse.org/WTP/Hotbug_Policy? A hotfix (or hotbug, patch update, whatever you call it) would at least be available to anyone looking for WTP updates directly within Eclipse. Managers would more likely be OK to update Eclipse via the standard channels, rather than having people manually copying an "unofficial" jar in eclipse/plugins dir. my 0.02€ I wasn't very clear. The fix/patch will definitely be in WTP 3.2.3 (Helios SR2) which is planned to be released last Friday of February. And in that case, yes, for those with Helios installed, nearly all types of installs would find the new/fixed release in the "find updates" action. And, fresh installs of EPP packages such as JEE IDE would have the included from the start. The "hotbug policy" is a whole different thing. That is a method by which non-committers can express their perceived "priority" for a bug, not just "severity". That's all that is. I was reading "hot bug" here as the type of fix where just one bug fix is made available independent of a regularly scheduled maintenance release. And that's the one that would not be found by the "find updates" action. A known, nasty limitation. It is a good, valid point, though, that if companies/managers have to direct their developers to "go and get this fix", then it would make more sense to get the patched feature from a software repository. But, patch attached here is a patched feature, and should be installable (after download) via p2, and that would play well with future updates, once it becomes available as part of the release. All that said ... I originally butted in here just to reply to the comments/requests for a hot bug so those users wouldn't feel you were being ignored. We do "hear" you and discussed in previous status meetings. Hope I didn't confuse the issue more. The conclusion of the status meeting was, and still is, if the project lead of this WTP component (Common Tools) wants an off cycle fix made available via our software repository, he can request it ... he is in the best position to judge if this bug's impact requires the extra work that takes. thanks for your reports and comments. Hope mine makes things a little clearer. I'll butt out now and let the project lead and primary committers carry on. *** Bug 333526 has been marked as a duplicate of this bug. *** This fix work only when we install the fix in dropins of the eclipse install folder. When we use an external configuration (with -configuration parameter in command line to launch eclipse) and we install the fix in the dropins folder at same level (see ***) it not work (no error log). (All my other plugins work very well in this dropins folder...) /externalConfFolder/ /externalConfFolder/configuration /externalConfFolder/dropins *** /externalConfFolder/p2 /externalConfFolder/artifacts.xml FYI, the fix is available for SpringSource Tool Suite users (https://issuetracker.springsource.com/browse/STS-1456), via the Extension tab of the STS Dashboard. While I salute the initiative, I'm saddened this has not been taking care of by Eclipse directly. (In reply to comment #28) > This fix work only when we install the fix in dropins of the eclipse install > folder. > When we use an external configuration (with -configuration parameter in command > line to launch eclipse) and we install the fix in the dropins folder at same > level (see ***) it not work (no error log). > (All my other plugins work very well in this dropins folder...) > /externalConfFolder/ > /externalConfFolder/configuration > /externalConfFolder/dropins *** > /externalConfFolder/p2 > /externalConfFolder/artifacts.xml Nobody have a solution for this problem with an external configuration for eclipse? Updating Web Tools to 3.2.3 on Eclipse 3.6.1 fixed my errors on a workspace that was previously failing to load. Thanks! *** Bug 341196 has been marked as a duplicate of this bug. *** *** Bug 335201 has been marked as a duplicate of this bug. *** |