Community
Participate
Working Groups
Created attachment 126520 [details] Stack trace There was a deadlock in our adopters product. Stack trace attached. The problem as I see it. Threads "Worker-12" and "Modal Context" are locked. "Worker-12" is a workspace change notification thread. It is acquiring the work manager lock between line 3 and 4 of its stacktrace. Between Workspace.run and Workspace.endOperation, the getWorkManager().endUnprotected(depth) is called which acquires the work manager lock. Having this lock the thread continues and comes to J2EEComponentClasspathContainer.update where the method JavaProject.getResolvedClasspath is called. JavaProject.getResolvedClasspath has a synchronized block over a PerProjectInfo object. This lock is hold Modal Context". "Model Context" is trying to create a project using an EjbFacetProjectCreationDataModelProvider and its operation. The thread is starting a workspace runnable. This leads to starting another 4 inner workspace runnables in DataModelPausibleOperationImpl.runOperation, FacetedProject.modify, JavaModelOperation.runOperation, JavaModelManager$PerProjectInfo.writeAndCacheClasspath. When the last inner workspace runnable (writeAndCachClasspath) is called it gets the PerProjectInfo in a synchronized block (see JavaModelManager.java:1188). After it gets the PerProjectInfo lock it tries to write a file. This calls Workspace.prepareOperation and then WorkManager.checkIn. The checkIn method tries to get the work manager lock. But it fails - this is hold by "Worker-12". Summarized. "Worker-12" is getting the locks in the order WorkManager and then PerProjectInfo. "Modal Context" is getting the locks in the order PerProjectInfo and then WorkManager. Since the lock are taken in a revers order a deadlock occurs. This is my understanding of the problem. I currently do not have a solution to the problem. "Worker-12" and J2EEComponentClasspathContainer.update are trying to acquire a lock that is out of their "scope". Acquiring any locks in a resource change event is dangerous. But not the J2EEComponentClasspathContainer is notified for the resource change. It is the org.eclipse.jem.workbench.utility.JavaModelListener that is processing the delta. Any assistance will be of great help.
Created attachment 127992 [details] Second deadlock. Different threads. This is another stacktrace. This time there are many SAP specific classes in the stacktrace, but the problem is the same. I am attaching it to be able to further investigate.
Created attachment 127993 [details] Third stacktrace. Different threads This is again the same deadlock, but with a different stacktrace. There are again many SAP specific threads and classes. Attaching to be able to further investigate. We currently can not find a workaround on our side. There is always the Thread "Worker-0", id = 18, state = BLOCKED, lock = org.eclipse.jdt.internal.core.JavaModelManager$PerProjectInfo@1439d6d, lock owned by thread id 79 Stack trace: org.eclipse.jdt.internal.core.JavaModelManager$PerProjectInfo.getResolvedClasspath(JavaModelManager.java:1054) org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1870) org.eclipse.jdt.internal.core.DeltaProcessingState.getRootInfos(DeltaProcessingState.java:265) org.eclipse.jdt.internal.core.DeltaProcessingState.initializeRoots(DeltaProcessingState.java:210) org.eclipse.jdt.internal.core.DeltaProcessor.processResourceDelta(DeltaProcessor.java:1741) org.eclipse.jdt.internal.core.DeltaProcessor.resourceChanged(DeltaProcessor.java:1923) org.eclipse.jdt.internal.core.DeltaProcessingState.resourceChanged(DeltaProcessingState.java:431) org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:288) org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:282) org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:148) org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:313) org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1022) org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1809) org.eclipse.core.internal.events.NotificationManager$NotifyJob.run(NotificationManager.java:39) org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) which locks the PerProjectInfo. But the PerProjectInfo is hold by J2EEComponentClasspathContainer.
*** This bug has been marked as a duplicate of bug 249930 ***
