Created attachment 13321 [details]
thread-dump

Unfortunately there seems to be an inconsistency in the state machine
of the CloneableEditorSupport that allows a thread to become waiting
for document opening but there is no thread that would wake it up:

java.lang.Object.wait(Native Method)

java.lang.Object.wait(Object.java:429)

org.openide.text.CloneableEditorSupport.openDocumentImpl(CloneableEditorSupport.java:546)

org.openide.text.CloneableEditorSupport.openDocumentImpl(CloneableEditorSupport.java:538)

org.openide.text.CloneableEditorSupport.openDocumentCheckIOE(CloneableEditorSupport.java:520)

org.openide.text.CloneableEditorSupport.openDocument(CloneableEditorSupport.java:515)

- locked <0x1304ec60> (a
org.openide.windows.CloneableOpenSupport$Listener)

org.netbeans.modules.java.JavaParserGlue.sourceToText(JavaParserGlue.java:626)

org.netbeans.modules.editor.java.NbJavaFoldMaintainer.updateFoldsForClass(NbJavaFoldMaintainer.java:460)


I did not find any thread in the dump that would seem to do a document
loading - please correct me if I'm wrong.

As the AWT is currently in
  [ideexec] 	at
org.openide.text.QuietEditorPane.firePropertyChange(QuietEditorPane.java:42)

  [ideexec] 	at
javax.swing.text.JTextComponent.setDocument(JTextComponent.java:401)

  [ideexec] 	at
org.openide.text.CloneableEditor$1.run(CloneableEditor.java:130)

  [ideexec] 	at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)

 
I suspect that the scenario can be something like:
1) closeDocument() is being done.
2) during that a thread comes into openDocument() but enters waiting.
3) closeDocument() finishes but the other thread is not notified.

Reassigning to openide/editor. Petre N. please let me know if you want
me to cooperate on fixing of this - I admit my portion of guilt on this :)

I'm really happy I do understand to what happened in this case
and I do know how to prevent this problem.
Moreover, I'm lovering priority, because ic ac hardly occur during
real user - IDE interaction.

The problem is simple, the default RP was overfloded with requests,
and as it tops at 50 paralel requests, it can't handle the loading of
the document (the loading request is waiting in the RP queue for a
free thread) and the usual RP priority-inversion safe-way can't
proceed because of wait/notify scheme used instead of Task.waitFinished.

Now, I'm a bit nervous about the number of started fold maintainers,
because they are the threads trying to fetch the documents.

First of all, they should be scheduled to a private RP instance, and
that RP should have much more limited throughput (probably 1, no need
to slow down the UI by way too much background paralel processing).

The second thing is - they probably got their timeslice after the
editor got already closed, and they didn't knew it, so provoked Java
source hierarchy to load the doc again.

Petre thanks for info.
 I will probably change the current behavior and eliminate the waiting
for the document to be loaded completely. Although I will ask the fold
maintainers early - before the doc actually gets loaded they should be
able to resolve the situation appropriately by checking for
doc.getProperty(Document.StreamDescriptionProperty) that will not be
set for the initial document. This should also eliminate this problem.
I of course rely on the current state that that property is being set
early before pane.setDocument() is called.

Another question - is that really necessary to have

                            Document doc = support.createStyledDocument(
                                    pane.getEditorKit());
                            pane.setDocument (doc);
                            pane.setEditorKit (null);

in CloneableEditor upon document closing?
 Although I understand that it ensures that the original document is
no longer held by the text component the component is going to be
released anyway. The
                        removeAll();
                        initialized = false;
is done afterwards which eliminates the pane from being displayed.

 The extra pane.setDocument() invoke the listeners triggered once a
document is being changed e.g. a new view hierarchy is going to be
built which has to consult the existing folds etc. so the whole
closing operation is less efficient than it could be.
 I have tried to comment-out the stmts and there is no exception
thrown and I expect no memory leak created as well. If there is no
other reason to retain the stmts then I vote to eliminate these.

Not waiting for CES.openDocument() - initializing maintainers
synchronously. The fold maintainers (e.g. the java fold maintainer)
will likely end up waiting for document opening indirectly anyway.
This should prevent both running out of RP thread limit and possible
deadlocks of the init-fold-RP with AWT.

Fixed in trunk:
Checking in
src/org/netbeans/modules/editor/LayerFoldMaintainerListProvider.java;
/cvs/editor/src/org/netbeans/modules/editor/LayerFoldMaintainerListProvider.java,v
 <--  LayerFoldMaintainerListProvider.java
new revision: 1.5; previous revision: 1.4

It seems like it works fine now, (verified in [nb_dev](200402171900))