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 186519 - AWT thread blocked for 22812 ms.
Summary: AWT thread blocked for 22812 ms.
Status: RESOLVED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Ant (show other bugs)
Version: 6.x
Hardware: All All
: P3 normal with 1 vote (vote)
Assignee: Jesse Glick
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2010-05-21 15:25 UTC by Exceptions Reporter
Modified: 2011-10-12 22:30 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 167011


Attachments
nps snapshot (9.22 KB, application/nps)
2010-05-21 15:25 UTC, Exceptions Reporter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2010-05-21 15:25:55 UTC
Build: NetBeans IDE 6.8 (Build 200912041610)
VM: Java HotSpot(TM) Client VM, 11.3-b02, Java(TM) SE Runtime Environment, 1.6.0_13-b03
OS: Windows XP
Maximum slowness yet reported was 22812 ms, average is 18133
Comment 1 Exceptions Reporter 2010-05-21 15:25:59 UTC
Created attachment 99322 [details]
nps snapshot
Comment 2 Martin Entlicher 2011-01-14 13:23:58 UTC
IMHO Hyperlink.outputLineAction() should post the expensive execution to RP thread.
Comment 3 Jesse Glick 2011-03-07 23:59:29 UTC
core-main #19f77c2ad9f8
Comment 4 Quality Engineering 2011-03-09 05:34:16 UTC
Integrated into 'main-golden', will be available in build *201103090000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/19f77c2ad9f8
User: Jesse Glick <jglick@netbeans.org>
Log: #186519: AWT thread blocked for 22812 ms.
Comment 5 greggwon 2011-09-09 14:19:37 UTC
The pattern used to fix this issue, looks very much like the same pattern that SwingWorker and other tools use regarding creating a background thread to do non-UI work, and then submitting UI work to the event queue.  It seems like Netbeans should have already standardized this activity. My issue, http://netbeans.org/bugzilla/show_bug.cgi?id=175342, is one such example of past suggestions to standardize this, so that the API could be used by all to get the right results of removing EDT use from anything but GUI updates.  It's even possible for execution to be "halted" while the background task is executing, even from an EDT invocation, by using an event loop, as you all already know about.  

The use of background threads for non-GUI work will greatly enhance the ability of the developer to manage their work flow much more readily when scanning and other activities block other threads of execution.
Comment 6 Jesse Glick 2011-09-09 16:59:41 UTC
(In reply to comment #5)
> The pattern used to fix this issue, looks very much like the same pattern that
> SwingWorker and other tools use regarding creating a background thread to do
> non-UI work, and then submitting UI work to the event queue.

It is similar.

> It seems like Netbeans should have already standardized this activity.

Well there is no coherent threading model for NetBeans code, and given the size of the code base and extent of public APIs, there probably never will be. Bugs are fixed on a case-by-case basis. This particular case was trivial to fix once noticed; anything involving locks is much harder.
Comment 7 greggwon 2011-09-12 12:16:02 UTC
Jesse, I can appreciate that you have a lot more knowledge about the totality of netbeans sources than I do.  However, as one of the users, I have had to deal with all of the "in my face" EDT threading issues which keep me from using the IDE to do what I need to get done.

Keeping the EDT from processing events, as a means of locking, or execution flow control, just does not feel right, and it's something that I've spent a lot of time, on my applications, to avoid.

For myself, it's natural to manage this issue in highly interactive applications by using work flows which can be cancelled so that it is possible to let the user redirect themselves to accomplish things.

The big issue for netbeans, still, 6 or more years later since I started using it, is that the EDT thread is used to call into code that can be held up by locking.

The netbeans team has been cleverly inserting more and more EDT processing control between the IDE and Swing/AWT to try and catch problem areas, such as this issue found, and has been working through repairing the designs to make them work better.

But, in the end, when interacting with the EDT issue, there is an extremely consistent pattern.  Work either needs to be done on-the-EDT or it should be done off-the-EDT.  When I've looked at various parts of netbeans code, and the hundreds of stack traces I've created when stuck without IDE interaction (through CRTL-Break or CTRL-\ in a console window), it seems very clear that there isn't a system design that provides an encapsulation of this idea so that developers reading existing code can understand what types of work particular APIs do.

The checks in some of the APIs that announce in the logs that you should be making the call on the EDT and you are not are an example of the early recognition that users needed help understanding when to use the EDT.

This may have resulted in a lot of people using the EDT always so that they'd never get that message, and thus they'd also not have to manage the complexities of switching contexts and synchronizing execution with background threads.

At this point, I just don't get why this doesn't seem important.  You guys are spending time dealing with the lack of "design".  The users are punished with poor behaviors because the APIs don't create a mechanism that works for developers.  There are several different "wait, I'm busy" mechanisms which are visible in the IDE today, trying to manage the synchronization.  The locking while scanning now has a popup that happens automatically so users know that API calls from "undesigned" code into the scanning/lookup mechanisms will at least show the user why they have to wait.

It just feels so cheap and so fragile and it looks quite a mess.  I know that you all are probably well tired of hearing about this topic, over and over.  But it's one of those things, for me, that once I made the commitment to design one way to do this in my applications, it was like magic.  Suddenly, I could give the user a lot more control over how they used my applications.

I really think that this is a much needed change in Swing/AWT programming design.  The Swing/AWT teams never made it much past SwingWorker, because, I guess, there were so many other people doing it.  But with Netbeans sitting around, as one of the visible RCPs, it would seem exactly the right place for a very effective and smart EDT interaction API to be.
Comment 8 Jesse Glick 2011-10-12 22:30:47 UTC
This is really off topic for Bugzilla. If you want to offer code contributions, nbdev is the place for discussion.