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.

Bug 170878 - AWT thread blocked for 36683 ms.
Summary: AWT thread blocked for 36683 ms.
Status: RESOLVED DUPLICATE of bug 171046
Alias: None
Product: javaee
Classification: Unclassified
Component: Code (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Marek Fukala
URL: http://statistics.netbeans.org/except...
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2009-08-25 14:58 UTC by Exceptions Reporter
Modified: 2009-09-18 11:12 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 156804


Attachments
nps snapshot (19.27 KB, bin/nps)
2009-08-25 14:58 UTC, Exceptions Reporter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2009-08-25 14:58:27 UTC
Build: NetBeans IDE Dev (Build 200908022240)
VM: Java HotSpot(TM) Client VM, 11.3-b02, Java(TM) SE Runtime Environment, 1.6.0_13-b03
OS: Windows XP, 5.1, x86
Maximum slowness yet reported was 36683 ms, average is 36683
Comment 1 Exceptions Reporter 2009-08-25 14:58:32 UTC
Created attachment 86631 [details]
nps snapshot
Comment 2 Petr Jiricka 2009-09-16 17:20:39 UTC
Tomasi, can you please help me understand this report? It looks like AWT is waiting in CloneableSupport.openDocumentImpl
for something, probably the "org.openide.text Document Processing" thread. When you look at this thread, most time is
spent in classloading and native file access stuff. So can we do anything about this? Should we reassign to platform?

There were some slowness reports in the JSP editor, see issue 171046 and issue 169863, but I am not sure they are
related, I think not (right, Marku?)
Comment 3 Marek Fukala 2009-09-17 07:13:12 UTC
The fixes are likely unrelated. As for me I do not see anything bad from the web perspective in the snapshot.
Comment 4 Tomas Pavek 2009-09-17 15:57:33 UTC
AWT is waiting in CloneableSupport.openDocumentImpl, but as Jarda noticed it is because
BaseJspEditorSupport.BaseJspEditor.componentActivated() calls getEditorPane() - which is blocking, waiting till the
document is opened. JSP editor perhaps should not require the document to be loaded when the TopComponent is just
activated. (You can normally see "Loading..." panel in the editor during document loading.)

So perhaps the componentActivated() method should check just this.pane instead of getEditorPane().

Note that CloneableEditor also fires EditorCookie.Observable.PROP_OPENED_PANES on editor support when done (part of fix
of issue 168415).
Comment 5 Petr Jiricka 2009-09-18 10:43:36 UTC
Marku, so should it be addressed on the JSP editor side?

Note that there is also issue 169469 - probably a duplicate?
Comment 6 Marek Fukala 2009-09-18 11:12:57 UTC
Hmm, I didn't look at the snapshot carefuly enought before, it is a duplicate of issue #171046. I am sorry. The issue
with the getEditorPane() in the componentActivated() has been already fixed.

*** This issue has been marked as a duplicate of 171046 ***