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.
Very serious regression problem - JNLP application build on platform 5.0/5.5 is unusable in JRE 6 (but works in JRE 5). It looks like there is a bug in either Platform core jars or in JRE 6, or in JRE 6 WebStart. Steps to reproduce - create Module suite, add some dummy module to it (not sure if it is necessary), change suite to "standalone" type in Properties, create JNLP distribution, deploy obtained .war to any server. Access master.jnlp in main dir. Whenever I do it using web start from java 5, it runs ok. If I do it using Java 6, application starts, netBeans platform splashscreen pops up and freezes on "Loading installed objects of modules" message. I checked both on Windows XP and Linux. The same is using Platform 5.0 and 5.5. No error in Platform logs. (Once I got popup during startup "netbeans java.lang.IllegalArgumentException: URI is not hierarchical" but I can't reproduce it). If you start the same application from NetBeans ("Run JNLP Application") it works.
Using Fedora Core 6, I run NB 5.0 on JDK 5.0u11 in a fresh userdir. Make new module suite project, default NB platform. Add one module to it. Change to standalone app, exclude IDE-related modules. "Run JNLP Application" works. Then I run "Build JNLP Application"; WAR created. In Runtime > Servers > Bundled Tomcat, I Start, then Stop. I copy the WAR to $userdir/jakarta-tomcat-5.5.9_base/webapps. I again Start Tomcat. /suite1 appears beneath Web Applications. Open in Browser shows a dir listing, so I copy the URL for master.jnlp. From a shell I then run /space/jdk5/bin/javaws http://localhost:8084/suite1/master.jnlp which works. The same using JDK 6 also works fine. So I cannot reproduce.
Strange it works for you. But it's good (means that it is not completely useless). But makes harder to reproduce. I use NetBeans 5.5 with Platform 5.0 and 5.5 registered. In both cases this does not work (I mean JNLP freezes during Platform startup) on Java 6 on Win XP SP2, and Ubuntu 6.10. I will try to check it on clean NetBeans intallation, if it can affect anything. Please also see http://www.nabble.com/Anybody-succeeded-running-NBPlatform-based-application-via-JNLP-on-Java-6--tf3290156.html#a9151306
If the java application stales, can't you generate a thread dump? Using jmap, or kill -s QUIT, etc.?
Created attachment 42179 [details] Dump from JDK6 jstack
Created attachment 42180 [details] Dump from JDK6 jmap -dump (bzipped)
Funny, but by chance I left frozen JNLP NetBeans application, and after long (several minutes) no-op, it suddenly went ahead and finally opened the main window. So now I may say that the application based on NBPlatform starts very fast in Java Web Start in Java 5, but in Java 6 it freezes (no activity of java process) on "loading installed objects of modules" step for about 20 minutes, and then wakes up and opens main window.
The long time freeze during splash screen, and the message "Loading installed objects of modules", it seem caused by Netbeans query / download again from webserver (which host the webstart app) for the jar. So the freeze time is depending on the bandwith. See the log file below regarding "weird jar" My log file: >Log Session: Wednesday, May 16, 2007 2:22:47 AM WIT >System Info: Product Version = Citra FX 1.0 Operating System = Linux version 2.6.18-1.2798.fc6 running on i386 Java; VM; Vendor; Home = 1.6.0_01; Java HotSpot(TM) Server VM 1.6.0_01-b06; Sun Microsystems Inc.; /opt/jdk1.6.0_01/jre System Locale; Encoding = en_SG (citra); UTF-8 Home Dir.; Current Dir. = /home/tonny; /home/tonny/public_html/citra/webstart Installation; User Dir. = null; /home/tonny/.nbapp-citra Boot & Ext. Classpath = /opt/jdk1.6.0_01/jre/lib/resources.jar:/opt/jdk1.6.0_01/jre/lib/rt.jar:/opt/jdk1.6.0_01/jre/lib/sunrsasign.jar:/opt/jdk1.6.0_01/jre/lib/jsse.jar:/opt/jdk1.6.0_01/jre/lib/jce.jar:/opt/jdk1.6.0_01/jre/lib/charsets.jar:/opt/jdk1.6.0_01/jre/classes:/opt/jdk1.6.0_01/jre/lib/javaws.jar:/opt/jdk1.6.0_01/jre/lib/deploy.jar:/opt/jdk1.6.0_01/jre/lib/ext/sunpkcs11.jar:/opt/jdk1.6.0_01/jre/lib/ext/sunjce_provider.jar:/opt/jdk1.6.0_01/jre/lib/ext/localedata.jar:/opt/jdk1.6.0_01/jre/lib/ext/dnsns.jar Application Classpath = /opt/jdk1.6.0_01/jre/lib/deploy.jar Startup Classpath = ------------------------------------------------------------------------------- [org.netbeans.core.modules] Disabling openide load optimizations due to use of org.openide.compat Turning on modules: org.openide.util [6.8.22 200610171010] org.openide.modules [6.5.22 200610171010] org.openide.awt [6.7.22 200610171010] org.openide.options [6.4.22 200610171010] org.openide.dialogs [6.5.22 200610171010] org.openide.nodes [6.7.22 200610171010] org.openide.explorer [6.5.22 1 200610171010] org.openide.windows [6.5.22 200610171010] org.openide.text [6.9.22 200610171010] org.openide.actions [6.5.22 200610171010] org.openide.filesystems [6.4.22 200610171010] org.openide.loaders [5.9.22 200610171010] org.netbeans.bootstrap/1 [2.3.22 200610171010] org.openide.io [1.9.22 200610171010] org.netbeans.api.progress/1 [1.5.22 200610171010] org.netbeans.core.startup/1 [1.5.22 200610171010] org.netbeans.swing.plaf [1.5.22 200610171010] org.netbeans.core/2 [3.2.22.1 200610171010] org.openide.execution [1.8.22 200610171010] org.netbeans.core.output2/1 [1.7.22.1 1 200610171010] org.netbeans.core.execution/1 [1.9.22 200610171010] org.netbeans.modules.javahelp/1 [2.8.22 200610171010] kiyut.citra.modules.userguide [1.0 070515] org.netbeans.swing.tabcontrol [1.6.22 200610171010] org.openide.compat [6.4.22 200610171010] org.netbeans.modules.queries/1 [1.7.22 200610171010] org.netbeans.modules.favorites/1 [1.11.23 200610171010] org.jdesktop.layout/1 [1.3.23 1.0 200610171010] kiyut.citra [1.0 070515] org.netbeans.core.ui/1 [1.9.22 200610171010] org.openide.util.enumerations [6.4.22 200610171010] org.netbeans.core.multiview/1 [1.8.22 200610171010] org.netbeans.modules.settings/1 [1.10.33 200610171010] org.netbeans.core.windows/2 [2.7.22.1 200610171010] org.netbeans.modules.autoupdate/1 [2.16.22 200610171010] org.netbeans.modules.masterfs/1 [1.8.24 200610171010] [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-netbeans-modules-autoupdate.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-netbeans-api-progress.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-netbeans-modules-settings.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-netbeans-core-windows.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-netbeans-core.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-netbeans-core-ui.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-jdesktop-layout.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/app/kiyut-citra.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-netbeans-modules-javahelp.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-netbeans-core-output2.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-netbeans-modules-favorites.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-netbeans-core-multiview.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/app/kiyut-citra-modules-userguide.jar [org.netbeans.core.LookupCache] Weird jar: URL: http://localhost:8080/~tonny/citra/webstart/netbeans/org-netbeans-core-execution.jar
This bug also might be the result of Java 1.6 Webstart spec changing. see http://java.sun.com/javase/6/docs/technotes/guides/javaws/enhancements6.html especially the area Jar Indexing is fully supported now, and the JNLPClassLoader is now an instance of the URLClassLoader. Below is the part " The JNLPClassLoader was rewritten to extend URLClassLoader. This gives several powerful advantages. .. Finally, the URL returned for calls to ClassLoader.getResource() is now the proper JAR URL of the item on the net. In previous versions, this URL returned was a jar url of the file url item in the cache. By extending URLClassLoader, the cached location (if it exists) is meaningless, and it allows Java Web Start to operate without caching. "
The program seems to be blocked in org.netbeans.core.startup.NbURLStreamHandlerFactory$NbResourceStreamHandler$Connection.getHeaderField(NbURLStreamHandlerFactory.java:228) Jesse, that is very likely your code. Do you want to look at the problem?
Indeed, seems like the root problem is that we are now getting a slow jar:http: URL where we used to get a fast jar:file: URL. I wonder what the purpose of this change was. Seems to me that it should be backed out unless the authors of the JNLP container are prepared to change HttpURLConnection to look for JNLP caches and automatically translate network URLs. Trying to work around, please verify (use NB platform from a dev build): Checking in NbURLStreamHandlerFactory.java; /shared/data/ccvs/repository/core/startup/src/org/netbeans/core/startup/NbURLStreamHandlerFactory.java,v <-- NbURLStreamHandlerFactory.java new revision: 1.14; previous revision: 1.13 done
The workaround doesn't seem to help at all unfortunately. (Backported to release55.) After running Wireshark (TCP packet dump) while launching with Java 6U1 I can see a lot of HTTP GET requests like: GET /netbeans/org-netbeans-core-ui.jar HTTP/1.1 Cache-Control: no-cache (no If-modified-since) while showing the splash screen. I am trying to find a workaround for this, but I think you have much better chances of actually fixing it.
As the person the bug is happening to, you have a better chance of identifying where the unnecessary http URLs are being created, using a debugger or injected logging of some kind. I will try to work on it for 6.0 but no promises.
This might be also related with the following Java Bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6566201
The description of the bug from JRE you mentioned fits well to what I observed. Perhaps this is the explanation of this bug.
I was able to reproduce by running a suite targeted to the JNLP build on deadlock.netbeans.org. It does indeed work, it just takes a very long time to do anything that might load things from the system filesystem - menus seem to freeze when first opened, Options dialog unresponsive when first opened, etc. I don't think #6566201 is related.
Contrary to the jstack output originally posted, mine shows: .... at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:2031) at java.net.HttpURLConnection.getHeaderFieldDate(HttpURLConnection.java:444) at java.net.URLConnection.getLastModified(URLConnection.java:532) at org.openide.filesystems.XMLFileSystem$FileObjRef.timeFromDateHeaderField(XMLFileSystem.java:1110) .... Probably both possibilities exist, for different files. Anyway, I patched XMLFileSystem to not check timestamps for remote URLs. For me, this makes the app start up quickly under JDK 6. Checking in XMLFileSystem.java; /shared/data/ccvs/repository/openide/fs/src/org/openide/filesystems/XMLFileSystem.java,v <-- XMLFileSystem.java new revision: 1.20; previous revision: 1.19 done
Arguably a JRE bug that javaws offers you a cached local JAR in place of a network resource, but then fails to use the local cache to implement URLConnection.getLastModified. On the other hand, probably few applications would be checking the modification timestamp of their own resources. NB does it just as part of implementing the system filesystem layer, but it is probably not important, especially in JNLP mode where modules cannot be reloaded (so the timestamp of a SFS file could never change during a VM session anyway).
Confirmed on Netbeans 6-beta2, this is indeed fixed. It no longer keep requesting jar from the webserver Tested on - Netbeans: Netbeans 6-beta2 - Java: Java 1.6.0_03
Thanks, considering verified.