JDK-6664389 : Application performance is severely degraded when started using javaws 6.
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-02-18
  • Updated: 2011-02-16
  • Resolved: 2008-07-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u10 b23Fixed 7Fixed
Java SE 6

The problem is that the amount of network traffic has increased up to 25 times (20KB vs 578KB in one operation) compared to java 5. This has been traced down to every RMI request sent from our client to our server containing the list of all jars in the classpath for the application.

We can provide tcp dumps of a single (small) TCP stream conversation as well as have a test app to reproduce and test the problem.

The dumps clearly show what extra data is in each request, and it's clearly the whole classpath as specified in the JNLP file.

You can grab the dump files from these two URL's, and this shows the size of each RMI request on the wire.

Here are 2 test links, it is our app with an automated front end that runs the same test every time. The problem occurs after our app is loaded so our test procedure for us is...

   1. Load the app
   2. Start Logging
   3. Click "Start Test" button in app
   4. After "done" appears stop logging

The numbers refer to the version of java (jre) that the app will run under, not the webstart version.

As mentioned in the ticket this is a problem with javaws 6 so both jnlp's above should have the problem when launched with javaws 6 as opposed to javaws 5.

In our testing we looked at the files that are linked to java.exe when our app is running (after being webstarted). We can see that deploy.dll is from which ever version of webstart that is used. So ws6 + jre5 = deploy.dll 6 where as ws5 + jre5 = deploy.dll 5, I'm assuming, but haven't tested, that this is the same using jre6. Hope this info helps.


temp/java6.dump | wc -c
java5.dump | wc -c

This bug can be reproduced always.

Release Regression From : 5.0
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

EVALUATION possible fix: One option would be to have Java Web Start have by default a custom RMIClassLoader provider, with its getClassAnnotation method treats the JNLPClassLoader like the system class loader, returning the value of the "java.rmi.server.codebase" system property, and delegates to the default provider for everything else.

EVALUATION the difference is indeed related to JNLPClassLoader now extending URLClassLoader. RMI's marshalling format annotates serialized class descriptors with a "codebase URL path" in case the class needs to be dynamically loaded by the receiving party. (This is done in support of RMI's dynamic class loading functionality, which may or may not even be used by the customer's application.) The value used for this annotation is controlled by the RMIClassLoader provider's getClassAnotation method: http://java.sun.com/javase/6/docs/api/java/rmi/server/RMIClassLoader.html#getClassAnnotation(java.lang.Class) which the default provider implements as described here: http://java.sun.com/javase/6/docs/api/java/rmi/server/RMIClassLoader.html#getDefaultProviderInstance() Basically, if the class's defining loader is the system class loader or one of its ancestors, or if it is not a URLClassLoader, then the value of the "java.rmi.server.codebase" system property is used; otherwise, a string form of the result of invoking URLClassLoader.getURLs on the loader is used. In this case, I gather that the JNLPClassLoader is not configured to be considered the system class loader, but it is a URLClassLoader whose getURLs method returns the URLs of the application's class path, which in this case is quite lengthy.

EVALUATION using wireshark, i can reproduce the problem now. we see that extra packets are sent when the application makes RMI calls, and the problem is only seen with java web start 6. the extra packets contains http url to the application resources (classpath to JARs) it might be due to the change in classloader implementation in java web start 6. in 6, we extends URLClassLoader; in 5, we extends SecureClassLoader. asking our RMI team for more information/suggestion.

EVALUATION I ran the tests with both java web start 5u15, 6.0 and 6u10, and I don't see any difference. I even use a network packet sniffer and capture the network traffic. After I press the "start test" button in the application, I only see a single network packet being sent: -IPADDR= 16:17:42.390625 22 TCP 2144 200 It's the same for all 5u15, 6.0 and 6u10. Asking customer for more information.