United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6664389 Application performance is severely degraded when started using javaws 6.
JDK-6664389 : Application performance is severely degraded when started using javaws 6.

Details
Type:
Bug
Submit Date:
2008-02-18
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2008-07-09
Component:
deploy
OS:
windows_xp
Sub-Component:
webstart
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:
6u10 (b23)

Related Reports
Backport:

Sub Tasks

Description
FULL PRODUCT VERSION :
Java SE 6

A DESCRIPTION OF THE PROBLEM :
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.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
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.

ACTUAL -

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


REPRODUCIBILITY :
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.

                                    

Comments
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=192.18.43.225    16:17:42.390625    22    TCP     2144    200    218.185.69.76:11114

It's the same for all 5u15, 6.0 and 6u10.

Asking customer for more information.
                                     
2008-03-26
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.
                                     
2008-04-01
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.
                                     
2008-04-02
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.
                                     
2008-04-08



Hardware and Software, Engineered to Work Together