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.
NB 3.6 FCS build OS: Solaris 9 sparc/x86, 8 x86 (only) jdk: 1.4.2_04, 1.4.1_04 How to reproduce: 1) Invoke Swing browser (set it as used browser in Options) 2) type any external address (e.g. Help -> Release notes) 3) DEADLOCK (IDE freezes) - thread dump attached BTW: Solaris 8 sparc and Win2K works fine (an error in the status bar appears)
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?