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.
A deadlock occured while I was trying to create new BPEL file (see attached stacktrace). I've also encountered similar deadlocks several times in the past. All of them was caused by different order of aquiring BaseDocument's lock and XAM Model lock from different threads (actually, it was always BPEL Model lock, but according to Denis (aka 'ads') explanations BPEL Model locks are just wrappers aroud the XAM Model locks so the deadlock would occur anyway). I believe there should be a policy which states what order is legal and what is not. That policy should be applied either by Model's authors and Models consumers in cases where BaseDocument and XAM Model are used.
Created attachment 44104 [details] Deadlock's stacktrace
The description doesn't help much. Are you able to reproduce this problem? There are many models based on xam but have not seen deadlock before. Is there anything special to BPELModel? In any case, it'll help if we have a reproducible test case.
It's almost impossible to provide a 100% reproducable test scenario in this case (and I believe in any case with deadlocks). Here's what I can see from the attached stacktrace: AWT thread: AbstractDocumentModel, trying to handle insertUpdate event from BaseDocument, invokes AbstractDocumentModel.documentChanged() which is declared as "synchronized". By that time, AWT thread already holds a lock <0x041fbe60> (a org.openide.windows.CloneableOpenSupport$Listener) - i.e. event was fired under lock. So here we have the following order of aquiring locks: <0x041fbe60> (a org.openide.windows.CloneableOpenSupport$Listener) <0x042ff490> (a org.netbeans.modules.bpel.model.impl.BpelModelImpl) Default RequestProcessor thread: While doing a model synchronization, lock <0x042ff490> (a org.netbeans.modules.bpel.model.impl.BpelModelImpl) is aquired when entering AbstractModel.prepareSync() method. After that, as a part of a lookup process, the retriever comes into play and tries to open our document by invoking CloneableEditorSupport.openDocument(). There's a synchronized block in openDocument(). So, here we are trying to obtain locks in different order than AWT thread does.
From the stack trace, at org.netbeans.modules.bpel.core.BPELDataEditorSupport.reloadDocument( it seems you can reproduce this by making some change to the file from outside the IDE. Sam, please try to reproduce this by open a bpel in IDE, from outside the ide, using a text editor and keep adding/removing spaces and save the file. I am posting a fix. The idea is that background auto-sync request processor thread does not need to hold lock during prepare because the preparation result itself would be discarded during actual sync if changes were detected.
Created attachment 44279 [details] patch to fix possible deadlock by auto-sync
Created attachment 44307 [details] xam patch
Please replace the jar file with this new one and see if it makes any difference.
Samaresh, I believe you would agree that it's not effective to fight with deadlocks on an issue basis. It would be much easier to track them down if we'd had some anti-deadlock rules or policy to follow to avoid them. When the policy is in place, every single deadlock issue would expose a violation to a policy or a policy's breach. My concern here is to understand that policy when it comes to using XAM and NetBeans' Swing models (BaseDocument etc). When we were encountering such deadlocks in the past - it always required us to look carefully into XAM and BaseDocument's code to come up with the fix. For example, it's not obvious that we should not do sync() on XAM model from CaretListener.caretUpdate() (deadlock may occur). Is it possible to document valid usage scenarios in java doc?
XAM-based model implementation and usage is design to be rather simple. A description could be found at http://xml.netbeans.org/xam-usage.html. There is a few sentence about client code usage of sync. In general, sync/auto-sync should be robust. However, originally, the use-case of reloading the model from IDE-external changes is not of primary support, hence this bug. If you find something inconsistent with the above document, feel free to file a bug, we will either extends the document or improve the code.
zgursky, any updates?
Integrating the proposed fix. /cvs/xml/xam/src/org/netbeans/modules/xml/xam/AbstractModel.java, new revision: 1.12; previous revision: 1.11
*** Issue 112781 has been marked as a duplicate of this issue. ***
Verified.