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 120670 - Refreshing server nodes blocks AWT waiting for socket I/O
Summary: Refreshing server nodes blocks AWT waiting for socket I/O
Status: RESOLVED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Sun Appserver 9 (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Vince Kraemer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-31 16:45 UTC by _ tboudreau
Modified: 2007-11-01 16:01 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Thread dump (30.71 KB, text/plain)
2007-10-31 16:46 UTC, _ tboudreau 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2007-10-31 16:45:40 UTC 
I am behind a password protected proxy that does not seem to be working very well.  I expanded the node for a remote Glassfish V2 instance.  The UI 
remained responsive.  However, right clicking the node while it is refreshing causes the AWT thread to be blocked until background threads complete some 
socket I/O.  See attached thread dump.

"AWT-EventQueue-1" prio=6 tid=0x005151b0 nid=0x1828600 waiting for monitor entry [0xb429e000..0xb429ed10]
        at org.netbeans.modules.j2ee.sun.ide.dm.SunDeploymentManager.refreshDeploymentManager(SunDeploymentManager.java:1349)
        - waiting to lock <0x0d9d9560> (a org.netbeans.modules.j2ee.sun.ide.dm.SunDeploymentManager)
        at org.netbeans.modules.j2ee.sun.ide.j2ee.runtime.nodes.ManagerNode.getDeploymentManager(ManagerNode.java:163)
        at org.netbeans.modules.j2ee.sun.ide.j2ee.runtime.actions.ViewLogAction.enable(ViewLogAction.java:136)
        at org.openide.util.actions.NodeAction$DelegateAction.resultChanged(NodeAction.java:611)
Comment 1 _ tboudreau 2007-10-31 16:46:25 UTC 
Created attachment 52149 [details]
Thread dump
Comment 2 Vince Kraemer 2007-10-31 19:00:46 UTC 
this looks like an easy fix... I don't know how to test it though, since the steps to reproduce it are a bit vague.
Comment 4 _ tboudreau 2007-11-01 16:01:37 UTC 
Probably something like
 - set a boolean flag when I/O starts
 - if EventQueue.isDispatchThread(), assert that the flag is false

that won't be great at catching similar problems, but it's something.  Probably you need a non-blocking call to determine if the status is unknown and actions 
should disable themselves if the status is unknown.  Or wrap the thing that would block in a facade with the same methods that can check if I/O is happening 
and return some reasonable value if I/O is happening and publish a change when it is done, if you don't want to change all the code that might call the 
existing method.