> I assume because you are posting in this forum that
> you have developed a Java EE application and are
> deploying it to GlassFish and your frustration comes
> from the built-in support for launching app clients
> using Java Web Start. I ask because you didn't refer
> to GlassFish in your post. (You did mention the
> number of JARs.) I just want to make sure you are
> not talking about a non-Java EE application launched
> using Java Web Start from a standard web container
> (either the web container that is part of GlassFish
> or some other web server).
As I pointed out we are in the middle of developing a JAVA EE application.
At the moment of the issues we were using SJAS 9 update 1. We did start using JWS, but later on i'll explained why we are not using it anymore.
>
> Assuming you are using GlassFish and the built-in
> Java Web Start support, what build of GlassFish are
> you using? Have you had the same problems - or the
> absence of problems - with other builds?
We understand that SJAS 9 is sun adoption of GlassFish project, so we think that we are in a GlassFish environment. This is our first usage of GlassFish project.
>
> What release of Java are you using? Have you had the
> same problems - or the absence of problems - with
> other releases?
On the development site we are using Sun Java Build 1.6.0_01-b06.
We've tested on Clients running Java 1.6 and Java 1.5_07.
>
> The issue with the large number and large size of
> JARs that are needed is well-known and
> much-discussed. If you've read some of the other
> posts related to the Java Web Start support in
> GlassFish in this forum you know it's something we're
> very eager to address in the next major release of
> GlassFish. We know this is a hardship, and we wish
> we could have done something about it already. It
> just was not feasible with the time and resources we
> had. I know that doesn't help you now.
We were trying during this weekend the Hessian/Burlap protocol, since we are
running out of time, we need to solve the problem now. Our client deployment is
now reduced to 2.1Mb.
If useful, what I think is that jars are very dependent to each other, so if i only need one feature of the EE implementation, I'll finish releasing the whole jar's into the client. Maybe recomposing jars into working units might help. Java design allows you to have the same class repeated in several jars, even that is not a good technique, certainly is a practical one. Am I using EJB? a simple and non dependent client jar for EJB, using Web services? a simple independent jar for Web services. My 2 cents.
>
> Also, I also hope you know that this large download
> is needed only for the first app client launch
> performed from the server. Future launches of any
> app client - the same one or different ones - from
> the server do not repeat the big download.
We do know that, but webstart is not our preferred client launch method, cause we
need to send client dependent parameters.
>
> You referred to manual configuration that is
> required. Please be more specific...what
> configuration are you referring to?
I was referring to the client side, we have decided to package client jars and libs to deploy on the client, because on jnlp, you have to go into client deployment directory and manipulate some xml to have a sucessfull conection to a server. That is not very difficult, in fact is quite easy, but on several client .... On our approach a simple start up parameter will do, and can be automatically done on the client with a simple script. That's a lot easier than let jnlp do it trick and then go into each client to set it up.
>
> The slow performance you mentioned... Is this
> happening after the download has completed before you
> see the initial GUI display from your app client? In
> response to user actions in the GUI? At some other
> time?
I am developing on a 1.83GHZ DuoCore with 2GB ram, and overall performance just look okey. Testing the gui client on a Ubuntu Feisty Linux 1.2GHZ Athlon, component rendering is not smooth, RMI is pretty slow (seems that the marshalling/unmarshaling takes has a lot of overhead).
I really hate to compare technology, but we did test using Hessian, and performance on the same client is noticeable much better. We will try to do both tests on a Ubuntu Edgy Linux client running at 800MHZ 256MB ram, after we upgrade it's java to 1.6. By the way, gui does not render object well if using 1.5_07 java implementation.
>
> Is there any logging output in the server's
> server.log file that might indicate any problem?
> This might help identify the cause of the hang. Did
> you use the jstack utility to dump the thread
> stacks?
The hang that we experienced, did not report any exception at all, everything was performing but at an incredible slow rate. Kind of remind me when you have low memory and begin to do swaps of large memory blocks that are needed at the same time in memory to perform a specific task. A few minutes later CPU usage went up to 100% on a java process (can't tell if Tomcat, or SJAS). About 15 minutes later we've decided to turn off our server (YES unplug it from the outlet). The server is a 3.0GHZ P4 4GB ram.
>
> - Tim
Thanks Tim, this is one of the reason that we stick to Java, the community support is REALLY into supporting...
Federico
[Message sent by forum member 'freddyforjava' (freddyforjava)]
http://forums.java.net/jive/thread.jspa?messageID=221505