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.
Created attachment 99181 [details] Thread dump Hi, I was about to XSLT Transform a XML file. I took a lot of time the very first time I did it (didn't took so long the second time). During this first time I thought it was a threading issue (as the UI was not responsive during this time) so I took a thread dump of the JVM (attached). The interesting parts I see are the "AWT Event Queue" "AWT-EventQueue-1" prio=6 tid=0x06263c00 nid=0xf34 in Object.wait() [0x086ee000..0x086efb14] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x126509f0> (a org.openide.loaders.DataObjectPool) at java.lang.Object.wait(Object.java:485) at org.openide.loaders.DataObjectPool.waitNotified(DataObjectPool.java:537) - locked <0x126509f0> (a org.openide.loaders.DataObjectPool) at org.openide.loaders.DataObjectExistsException.getDataObject(DataObjectExistsException.java:71) And this "RequestProcessor" "Default RequestProcessor" daemon prio=2 tid=0x03f6bc00 nid=0x118 in Object.wait() [0x0533f000..0x0533fb94] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x126509f0> (a org.openide.loaders.DataObjectPool) at java.lang.Object.wait(Object.java:485) at org.openide.loaders.DataObjectPool.waitNotified(DataObjectPool.java:537) - locked <0x126509f0> (a org.openide.loaders.DataObjectPool) It seems to me that the DataObjectPool.wait() is causing some trouble here, but I'm not sure, so I'm submitting this for your review.
As far as I can guess from the thread dump: 1. "Folder recognizer" is blocked in XMLDataObject.<init> by MutualExclusionSupport - that means there is an open OutputStream for the fileobject and the system waits for it to be closed. 2. other threads wait in DataObjectExistsException.getDataObject for the XMLDataObject.<init> to finish. 3. Who's writing a file? I guess the XSL transformation in in progress: org.netbeans.modules.xsl.transform.TransformPerformer$AbstractPerformer.fileOutput(TransformPerformer.java:403) Possible fixes: 1. Close the output stream first and only then call DataObject.find. 2. Don't query the mime type inside of XMLDataObject's constructor. Anyway assigning to XML module, as that is where the fix has to be done.
Nikita, please take a look.
Probably I should do both; there's (IMHO) no real need to keep the stream open past DO.find() in the transformation
Correction - getMIMEType() is called by Loaders themselves, so there's only a little advantage in lazy-recognizing; during XMLDO.<init> the MIME should already resolved & cached. We eliminate only the block when the cached FO is released before loader recognition and XMLDO.<init> According to the report/stacktrace, the visual defect is that the Folder recognizer thread blocks within DataObject.find() - and that may still happen in DataLoaderPool.allLoaders (calls fo.getMIMEType()) during LONG file operation (not exactly this case). The FolderRecognizer might be still stopped for ~2 sec (10 x 200ms).
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/e5bcb6e946ae User: Svata Dedic <sdedic@netbeans.org> Log: #186348: XMLDO performs lazy resolution of MIMEtype. TransformAction first unlocks, then invalidates DOs - potentially DO will be created once more needlessly
Fixed: http://hg.netbeans.org/jet-main/rev/e5bcb6e946ae
*** Bug 158561 has been marked as a duplicate of this bug. ***
*** Bug 179206 has been marked as a duplicate of this bug. ***