users@glassfish.java.net

RE: Maximum Deployment Size? was (RE: Cluster SynchronizationException)

From: Manfred Riem <mriem_at_manorrock.org>
Date: Mon, 21 Jul 2008 09:19:52 -0600

Hi Daniel,

Thanks, now people can find it easier ;)

Manfred

-----Original Message-----
From: Daniel.Adelhardt_at_Sun.COM [mailto:Daniel.Adelhardt_at_Sun.COM]
Sent: Monday, July 21, 2008 8:11 AM
To: users_at_glassfish.dev.java.net
Subject: Re: Maximum Deployment Size? was (RE: Cluster SynchronizationException)

Hi,

the problem may (I had similar issues in the past) be caused by the fact
that the node agent spawns a JVM for the sync process and uses the
default Xmx heap settings for that jvm. If you specify a larger setting
the issues should go away. So for syncing larger apps in a clustered or
distributed environment you should apply the following settings for each
node agent:

asadmin set domain.node-agent.<node-agent-name>.property.INSTANCE-SYNC-JVM-OPTIONS="-Xmx256m"

Using -Xmx256m for 256m max Heap is just a suggestion over the jvm
default. In my deployments that was sufficient to also sync apps with
over 50m .ear files.

Please have a look at:
http://docs.sun.com/app/docs/doc/819-3679/abdkk?a=view

Daniel




Manfred Riem schrieb:
> 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>


-- 
========================================================================
Daniel Adelhardt                        Tel:           +49 89 460082443
Software Architect                      Mobile:        +49 172 8417283               
Sun Microsystems GmbH                   Email:  daniel.adelhardt_at_sun.com
Sonnenallee 1
D-85551 Kirchheim-Heimstetten
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551
Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer 
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net