This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Is that correct there are code parts in AntBuildExtender which are synchronized on Class object : Sample 1 : public void addDependency(String mainBuildTarget, String extensionTarget) { ... synchronized (AntBuildExtender.class) { ... } } Sample 2 : Map<String, Collection<String>> getDependencies() { ... synchronized (AntBuildExtender.class) { ... } ... }
Created attachment 66834 [details] Thread dump
Should probably be using ProjectManager.mutex.
Reassigning to Milos.
I've made the synchronization based on AntBuildExtender instance, not class. Assuming the 2 threads each worked on top of different projects, the change should fix it. http://hg.netbeans.org/main/rev/8a553f8b7fed if you can still reproduce with this patch in, please add steps to reproduce and reopen. jglick: not sure how project mutex shall help. Both threads were already using project write mutex down the stack traces..
"Both threads were already using project write mutex" - no. The first thread was using PM.mutex write, and waiting for ABE. The second thread held ABE and was _trying_ to use PM.mutex write - hence the deadlock: a lock ordering conflict. Changing synchronization to an instance of ABE is unlikely to make any difference (assuming both threads were dealing with the same project). You need to remove use of any other monitor and use only PM.mutex. The thread dump is confusing because it looks like the top of the second thread is inside PM.mutex write access. In fact if you look at JavaEEWSSupportLookupProvider.java you'll see that the body of the mutex access is calling jaxWsModel.write(). The second thread is not in this Runnable any more; it is exiting the FS.AtomicAction, which is then notifying FS listeners (I hope without holding PM.mutex any longer). That is to say, the top of the second thread could as well have been something like ... EjbJaxWsLookupProvider$1$2.fileChanged ... FCLSupport.dispatchEvent ... <some unrelated FS call> ... RequestProcessor$Processor.run
Integrated into 'main-golden', available in build *200808081401* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/8a553f8b7fed User: Milos Kleint <mkleint@netbeans.org> Log: #143201 synchronize on instance, not class
Created attachment 67138 [details] New deadlock
Created attachment 67139 [details] Correct dump stack
Please ignore the 67138 attachment, 67139 is the right one.
Please, don't add dependencies if they are already there. There is no way in Ant Extender API to check if dependencies are already set or not.
http://hg.netbeans.org/main/rev/bf43dde96edf adding checks to AntBuildExtender to persist data only in case something actually changes.
Integrated into 'main-golden', available in build *200808141419* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/bf43dde96edf User: Milos Kleint <mkleint@netbeans.org> Log: #143201 only persist data when something actually changes