Bug 191378 - Freeze with ParentVersionError.getErrorsForDocument waiting for repo indices
Freeze with ParentVersionError.getErrorsForDocument waiting for repo indices
Product: projects
Classification: Unclassified
Component: Maven
PC Linux
: P2 (vote)
: 7.0
Assigned To: Antonin Nebuzelsky
Depends on:
  Show dependency treegraph
Reported: 2010-10-26 19:22 UTC by Jesse Glick
Modified: 2010-11-11 14:03 UTC (History)
0 users

See Also:
Issue Type: DEFECT

Sequence of thread dumps (7.28 KB, application/x-bzip2)
2010-10-26 19:22 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2010-10-26 19:22:07 UTC
Created attachment 102655 [details]
Sequence of thread dumps

In a fairly new user dir, I tried to open the properties of a POM project with pom.xml open. The IDE went to 100% CPU and heavy disk for several minutes, with the UI frozen, then settled into an actual deadlock.

1. Livelock: EQ is waiting for a lock on the POM since the customizer holds a lock while open. StatusProvider$StatusProviderImpl.findHints locks the POM while calculating hints, reasonably enough. The problem is that ParentVersionError.getErrorsForDocument then forces update of all (local & remote) indices.

Probably the indexer should have a way of returning quickly from e.g. getVersions for repos which are not yet indexed; it could *trigger* the creation of the index asynch, but it should not *wait* for it to be finished. See loadIndexingContext for the logic; perhaps this could take a boolean force param and return boolean success, and if index && !force, return false; then e.g. getVersions could pass force=false and return immediately if result of loadIndexingContext is false.

Not clear if all callers of RQ methods should behave this way (return early upon missing index); would certainly be useful for fixing part of bug #191313, and in any other case where the result is just intended to be informational. TBD whether there are some use cases where it is appropriate to wait for indexing to complete.

2. Deadlock: some problem in POMModelImpl/AbstractModel with lock ordering. Seems that startTransaction both acquires a monitor on the model *and* acquires a semaphore, which seems inherently prone to deadlock. Here EQ has the monitor and is waiting for the semaphore, while "StatusProvider" thread holds the semaphore and is waiting for the monitor. Perhaps a bug in XAM/XDM.
Comment 1 Antonin Nebuzelsky 2010-11-10 16:37:47 UTC
Let's focus on #1 in this issue. Changing the summary.

#2 is now tracked separately in issue 191796.
Comment 2 Antonin Nebuzelsky 2010-11-11 14:03:06 UTC
core-main #618575a86d91

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