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.
| Summary: | Deadlock when refreshing DomainRootNode | ||
|---|---|---|---|
| Product: | serverplugins | Reporter: | Jiri Skrivanek <jskrivanek> |
| Component: | Sun Appserver 9 | Assignee: | Vince Kraemer <vkraemer> |
| Status: | VERIFIED FIXED | ||
| Severity: | blocker | CC: | issues, rkubacki |
| Priority: | P2 | Keywords: | PERFORMANCE |
| Version: | 5.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 97688 | ||
| Bug Blocks: | |||
| Attachments: |
Thread dump.
Similar thread dump when stopping server while IDE is shutting down. NB5.5.1 thread dump. |
||
|
Description
Jiri Skrivanek
2007-01-18 13:18:18 UTC
Created attachment 37485 [details]
Thread dump.
Created attachment 37487 [details]
Similar thread dump when stopping server while IDE is shutting down.
this (and other uses of AMX) probably need to be posted to the RequestProcessor.... Checking in DomainRootNode.java; /cvs/serverplugins/sun/appsrvbridge/src/org/netbeans/modules/j2ee/sun/ide/runtime/nodes/DomainRootNode.java,v <-- DomainRootNode.java new revision: 1.6; previous revision: 1.5 Verified. The same issue is reproducable in NB5.5.1 beta. The fix should be merged from trunk into release551 branch. Created attachment 38859 [details]
NB5.5.1 thread dump.
this is fixed and verified in the trunk. 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 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. killing the app server releases the deadlock. 5.5.1_candidate status whiteboard removed *** Issue 97434 has been marked as a duplicate of this issue. *** fixed in trunk (since 20 Jan 2007) The first thread dump has elements from the thread dumps associated with 97082... Verified |