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: | Swing browser - deadlock on external address | ||
---|---|---|---|
Product: | platform | Reporter: | zikmund <zikmund> |
Component: | Window System | Assignee: | _ tboudreau <tboudreau> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | lkishalmi |
Priority: | P3 | Keywords: | THREAD |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Thread dump |
Description
zikmund
2004-04-09 16:12:51 UTC
Created attachment 14345 [details]
Thread dump
Reassigne for evalutaion .... This is not deadlock. The awtEvetnt queue is waiting for connection to the socket of html. I'm, not sure if is better solution to do at javax.swing.JEditorPane.setPage(JEditorPane.java:392) in request processor. Karel, many unix applications are not redrawn and don't work correctly when you are disconnected from the network. "AWT-EventQueue-1" prio=6 tid=0x00328e60 nid=0x15 runnable [edf7e000..edf7fc30] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) - locked <0xef8c1e98> (a java.net.PlainSocketImpl) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) The problem is, that this appears even in the case, that you are connected to the internet, but through the firewall/proxy (e.g. SUN case). I suppose Swing browser doesn't have any settings for it. Anyway I think all potentially long waiting actions should not be done in AWT threads. I would like not to think about this bug as a standard unix application behavior -- waiting 5 minutes (or more) for an internet connection can't block whole application where the browser is only a small part. See JDK's bug 4714674 Reading through the source for JEditorPane, I don't see any reason why setting the URL couldn't always be done by replanning to some other thread - the loading work is done on its own thread anyway - it's only the preliminaries we need to shuffle off of the AWT thread ourselves. Implemented - works fine. Also improved error messages and bad url handling a bit. Checking in src/org/openide/awt/Bundle.properties; /cvs/openide/src/org/openide/awt/Bundle.properties,v <-- Bundle.properties new revision: 1.27; previous revision: 1.26 done Checking in src/org/openide/awt/HtmlBrowser.java; /cvs/openide/src/org/openide/awt/HtmlBrowser.java,v <-- HtmlBrowser.java new revision: 1.92; previous revision: 1.91 done Checking in src/org/openide/awt/SwingBrowserImpl.java; /cvs/openide/src/org/openide/awt/SwingBrowserImpl.java,v <-- SwingBrowserImpl.java new revision: 1.30; previous revision: 1.29 done Reopening - it still blocks AWT thread (same steps with Release Notes). Build 200407271830 on Sol9 x86, JDK 1.5.0-beta3-b59. Try it now. Checking in SwingBrowserImpl.java; /cvs/openide/src/org/openide/awt/SwingBrowserImpl.java,v <-- SwingBrowserImpl. java new revision: 1.31; previous revision: 1.30 done Verified. I've been testing NB 4.0 beta 1 for a while and found the following: It seems the current implementation brings up the JDK 1.4.1 bug NPE at getHeaderField call on a jar URLConnection. This did not occured before. Setting the org.openide.awt.SwingBrowserImpl.do-not-block-awt sysprop to true has eliminated this problem. Should this property enabled by default? |