Bug 191378

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.