users@glassfish.java.net

Re: Very slow start-up of Java Web Start Application Client Container (JWS-

From: <glassfish_at_javadesktop.org>
Date: Wed, 22 Aug 2007 08:14:30 PDT

[Privately, Steve pointed me to his application files which I've deployed on my system. He and I have both been using a patched copy of one of the GlassFish JARs to provide some timing information in the log output.]

There seem to be two things going on.

One, the system I am using (WinXP Pro, dual-CPU 2.6 GHz with 3 Gb or RAM) seems to start the client faster than yours, for whatever reason. My Java Web Start launches of the client take about 15 seconds. I know you reported - and the timings showed - that your launches take about a minute.

Second, on my system launches using the appclient script take about 8 seconds (approx. half the time it takes me to launch using Java Web Start). Why?

I had some suspicions why the Java Web Start launches are slower, but to be sure I used the NetBeans profiler on both the Java Web Start launch and the appclient launch. (I reset the data collection after Java Web Start had prompted for the certificate to take out the work done by Java Web Start itself before transferring control to the ACC.)

After a quick look, it appears that most if not all the additional time is due to security manager usage. During a Java Web Start launch the security manager is enabled by Java Web Start; by default (in my local installation) the security manager is turned off for appclient launches.

On Windows, file operations are particularly expensive (at least compared to other operating systems) and there are a lot of file operations with the many JARs that are part of the EAR and, therefore, are bundled into the app client JAR. This costs performance in both types of launches, but moreso during Java Web Start launches due to the security manager's involvement.

In both types of launches, a considerable amount of time goes to the validation of the EJB pieces. This seems unnecessary for the ACC to do on the client side, but the behavior in the archive-handling classes that are used by both the ACC and the server side is to validate, and so all those EJB submodules are being validated during either type of launch, appclient or Java Web Start.

I go back to one of my earlier thoughts about whether it's possible for you to repackage some of the classes in the app to reduce the number of EJB submodules, perhaps relying more on packaged libraries. That would help in several ways: fewer JARs to be expanded, fewer EJB submodules to be validated on the client side, etc.

- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]

http://forums.java.net/jive/thread.jspa?messageID=232021