Bug 197208 - Freeze adding test to module
Freeze adding test to module
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Maven
7.0.1
PC Linux
: P2 (vote)
: 7.0.1
Assigned To: Jesse Glick
issues@projects
: 7.0_WAIVER_APPROVED, PERFORMANCE, THREAD
Depends on: 201282
Blocks: 190041
  Show dependency treegraph
 
Reported: 2011-03-29 21:55 UTC by Jesse Glick
Modified: 2011-08-24 19:12 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
Thread dump (31.83 KB, text/plain)
2011-03-29 21:55 UTC, Jesse Glick
Details
Still frozen after indexing complete, so a true deadlock (27.99 KB, text/plain)
2011-03-29 21:56 UTC, Jesse Glick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2011-03-29 21:55:35 UTC
Created attachment 107370 [details]
Thread dump

Dev build. Had created an nbm-packaging project from snapshot archetype (no junit dep), and asked to add a JUnit test to it. When I clicked Finish, the IDE froze while reindexing all repos. Not yet sure what is waiting for what.
Comment 1 Jesse Glick 2011-03-29 21:56:03 UTC
Created attachment 107371 [details]
Still frozen after indexing complete, so a true deadlock
Comment 2 Jesse Glick 2011-03-30 22:02:45 UTC
No time to fix in 7.0 now; no other known occurrences; observed in a dev build but probably possible in 7.0 as well.

Things noted:

1. junit.wizards.EmptyTestCaseWizardIterator.instantiate runs synchronously in EQ; probably should create a progress handle. Would not be a fix the problem but might at least reduce its severity by allowing you to e.g. save modified files from the UI.

2. EQ is waiting to enter a transaction in POMModelImpl. Thread dump does not make it obvious which thread, if any, is already in a transaction in the model. Probably maven.hints.pom.StatusProvider$StatusProviderImpl.checkHints(StatusProvider.java:127), which may have a lock ordering conflict with junit.DefaultPlugin.storeProjectSettingsJUnitVer(DefaultPlugin.java:1601). Note that this is in the older and more commonly used variant of checkHints (where there is no text selection); the new fix of bug #190041 (so far only in dev sources) adds a transaction lock to the less commonly used variant not implicated here.

If the guess in #2 is correct, then the simplest fix would be to remove the transaction lock in both checkHints variants, though I have no clue what race conditions that might introduce.

ParentVersionError is also a little odd because it is trying to load a project from an editor hint. But I do not see any other way it could work - parsing ../pom.xml as text would not pick up inherited fields easily.

StatusProviderImpl could perhaps enter ProjectManager.mutex in read mode before acquiring the transaction lock, which would order the locks properly. This would mean it would "know" that hint implementations are loading projects, which is poor encapsulation (one of the arguments for STM).
Comment 3 Jesse Glick 2011-04-11 21:20:06 UTC
core-main #06b1431458fb
Comment 4 Jesse Glick 2011-04-11 21:21:39 UTC
Fix presupposes 1cace8861cab and 5dd3d1dd5a8e.
Comment 5 Quality Engineering 2011-04-12 08:42:17 UTC
Integrated into 'main-golden', will be available in build *201104120401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/06b1431458fb
User: Jesse Glick <jglick@netbeans.org>
Log: #197208: Freeze adding test to module
Acquire Project.mutex before acquiring XAM transaction lock, since ParentVersionError will need it anyway.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo