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: | Platform-based JNLP app using remote platform extremely slow in Java 6 | ||
---|---|---|---|
Product: | platform | Reporter: | gborkowski <gborkowski> |
Component: | Module System | Assignee: | Jesse Glick <jglick> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jtulach |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Dump from JDK6 jstack
Dump from JDK6 jmap -dump (bzipped) |
Description
gborkowski
2007-03-01 11:38:47 UTC
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. |