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 92771 - Deadlock when refreshing DomainRootNode
Summary: Deadlock when refreshing DomainRootNode
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Sun Appserver 9 (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Vince Kraemer
: 97434 (view as bug list)
Depends on: 97688
  Show dependency tree
Reported: 2007-01-18 13:18 UTC by Jiri Skrivanek
Modified: 2007-03-15 10:39 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Thread dump. (26.69 KB, text/plain)
2007-01-18 13:20 UTC, Jiri Skrivanek
Similar thread dump when stopping server while IDE is shutting down. (16.00 KB, text/plain)
2007-01-18 13:35 UTC, Jiri Skrivanek
NB5.5.1 thread dump. (18.43 KB, text/plain)
2007-02-23 12:38 UTC, Jiri Skrivanek

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2007-01-18 13:18:18 UTC
AWT queue is freezed forever while DomainRootNode is being refreshed. I think
reading from URLConnection.getInputStream() should be done outside of AWT queue.
To reproduce:

- add Glassfish server to IDE
- set Swing HTML Browser as default web browser (Tools|Options)
- create a web application from template
- toggle breakpoint in index.jsp
- start debugger F5 and wait until it stops at breakpoint
- finish debugger
- go to Runtime view and expand nodes under server node to see deployed web
- start debugger again and wait for breakpoint
- finish debugger
- repeat start/stop debugger and sooner or later your IDE will freeze (see
attached thread dump).

Build 20070117-1056, JDK1.5.0_10.
Comment 1 Jiri Skrivanek 2007-01-18 13:20:31 UTC
Created attachment 37485 [details]
Thread dump.
Comment 2 Jiri Skrivanek 2007-01-18 13:35:10 UTC
Created attachment 37487 [details]
Similar thread dump when stopping server while IDE is shutting down.
Comment 3 Vince Kraemer 2007-01-18 15:21:30 UTC
this (and other uses of AMX) probably need to be posted to the RequestProcessor....
Comment 4 Vince Kraemer 2007-01-20 17:58:48 UTC
Checking in;
new revision: 1.6; previous revision: 1.5
Comment 5 Jiri Skrivanek 2007-01-22 11:43:28 UTC
Comment 6 Jiri Skrivanek 2007-02-23 12:37:39 UTC
The same issue is reproducable in NB5.5.1 beta. The fix should be merged from
trunk into release551 branch.
Comment 7 Jiri Skrivanek 2007-02-23 12:38:27 UTC
Created attachment 38859 [details]
NB5.5.1 thread dump.
Comment 8 Vince Kraemer 2007-02-26 23:32:53 UTC
this is fixed and verified in the trunk.
Comment 10 _ rkubacki 2007-02-27 18:26:23 UTC
To Jirka: please add PERFOMANCE keyword for bugs like this.

re fix: the code is very strange. Missing documentation doesn't help either.
What is happening here and what is expected behavior? If you can add a test it
would be more clear.

What I see: DomainRootNode ctor calls SU.iL to run refresh() in EDT. This looks
good because AppserverMgmtContainerNode#refresh() operates on nodes so it is
fine to call it in EDT. After this fix overriding DomainRootNode#refresh()
reschedules the job to RP and can call AppserverMgmtContainerNode#refresh() from
RP thread (is this correct?) or can call refresh again using SU.iL.

-0 for this fix. (Read I'm not vetoing but dislike this way of fixing.) I am
really curious who will review it before integrating to 5.5.1
Comment 11 _ pcw 2007-02-27 21:25:35 UTC
I reviewed the changes and the underlying code and Vince and I discussed this
issue at length today.

In short, the fix is not correct and I don't think this issue should be fixed
for 5.5.1 at all.  It changes a known bug (short window where, if within that
timeframe the server becomes stopped a break point, a concurrent refresh of the
runtime tab will block AWT indefinitely) for an unknown bug, namely creating,
deleting, and updating Nodes on a background thread rather than AWT which could
subsequently cause AWT deadlocks and this potential for this would be all the
time, not just when the server might be stopped at a breakpoint (as is the case
of the known bug.)

The correct fix will be much more complicated and while it should be done for
6.0, I think it is too complex to do for 5.5.1.

I also think there is a work around for this bug (that I've asked Vince to
verify) that if this situation occurs, you can kill the appserver process and
the IDE should wake up again shortly, as the blocking code should receive an
exception at that point.  Not very nice, but if the user has unsaved changes, it
offers a way to save the data rather than lose it.

Comment 12 Vince Kraemer 2007-02-27 22:57:45 UTC
killing the app server releases the deadlock.
Comment 13 Martin Schovanek 2007-03-06 15:34:07 UTC
5.5.1_candidate status whiteboard removed
Comment 14 Vince Kraemer 2007-03-14 17:53:06 UTC
*** Issue 97434 has been marked as a duplicate of this issue. ***
Comment 15 Vince Kraemer 2007-03-14 18:24:16 UTC
fixed in trunk (since 20 Jan 2007)

The first thread dump has elements from the thread dumps associated with 97082... 
Comment 16 Michal Mocnak 2007-03-15 10:39:17 UTC