Hi there,
It seems that you have nailed down the problem. We now need a Glassfish engineer
answer the question about the deployment size.
If there is a maximum the entire Glassfish user base needs to know about it.
Eduardo: can you have someone shed some light on it?
About your java.net user account see
http://www.java.net/ and send a password
Reminder that should send it to your primary email account ;).
Manfred
-----Original Message-----
From: glassfish_at_javadesktop.org [mailto:glassfish_at_javadesktop.org]
Sent: Sunday, July 20, 2008 11:20 PM
To: users_at_glassfish.dev.java.net
Subject: Re: RE: RE: RE: RE: RE: RE: RE: Cluster SynchronizationException
I may have narrowed down the problem or at least identified the steps to reproduce it.
The the OutOfMemoryError occurs when starting a new node instance in a cluster
where the total size of the deployed artefacts (in this case several war files) exceeds
30MB.
I have executed the following steps several times and consistently see OutOfMemoryError:
1. From the DAS console, create a new cluster.
2. Create a new node agent on a different server from the DAS. Don't start it yet.
3. From the DAS console or asadmin, add a new instance to the cluster on the
node agent created in step 2.
4. Using asadmin, deploy over 30MB worth of war files into the cluster.
5. Start the node agent.
I'm not sure if this is repeatable under MS Windows.
I have tried a few dummy deployments where the total size of war files was just under
30MB. The node agent started, created and synchronized the instance directory
successfully. I was also able to stop and start the instance successfully from the DAS.
When the total deployment size was just over 30MB the node agent failed to start with
an OutOfMemoryError.
So introducing a new node to an established cluster fails in this scenario or at least it does for me.
Testing this the other way around by incrementally deploying several applications in
to a cluster where the instances are already running it is possible to go beyond
a total deployment size of 30MB. I have not tested the deployment of a single 30+MB
war file as yet.
I'm still not sure if this is causing the original “hanging synchronization” problem when
starting and stopping an instance. The reason why I say this is that I tested the case
where just over 30MB of war files was incrementally deployed into a node and then I
stopped and started the instance. It took a while but completed successfully.
However, when the total size of incrementally deployed war files greatly exceeds
30MB (say 50MB) the DAS hangs when starting the instance.
Some of the war files that we have are quite large – a result of transitive
dependencies in maven. We may be able to prune things down a bit, but if this
there is a deployment size limitation, this just delays the problem.
Is there a limit to the total deployment size that you know of and if so is there
some configuration property that can be set somewhere to at least work around
the problem in the short term?
By the way, would you still like to see the configurations files?
Also I am new to the dev.net site and still finding my way around. I noticed in my
profile that I also have a dev.java.net email account name, but no way of accessing it.
Is this something that has to be activated?
Thanks for helping and being patient.
[Message sent by forum member 'gussie' (gussie)]
http://forums.java.net/jive/thread.jspa?messageID=287971
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net