You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Martin Ritchie <ri...@apache.org> on 2010/06/04 13:07:53 UTC
[Java] Build PermGen issues
I've been having a look at our PermGen issues.
Whilst I have not got to the cause of the problem I have ruled out the
new use of the Felix OSGi container. Typicall PermGen OOM issues are
caused by creating a lot of class loaders. The fact that we start and
stop the inVM broker a lot means felix gets a chance to create lots of
classloaders. However, the permgen probem still occurs if we disable
felix (causing thoses tests that require it to fail).
If you want to take a look at what is in the PermGen I believe the
heap dump should contain details, which you can get using:
export ANT_OPTS="--XX:+HeapDumpOnOutOfMemoryError"
in the mean time I've just increased the PermGen size locally as follows:
export ANT_OPTS=-XX:MaxPermSize=256M
There are a number of things that are stored in PermGen beyond
classes, things like String.iterns. So hopefully we can make our tests
clean up better so we don't have to set an ANT_OPT value. One
alternative would be to change our ant iterate task to fork a new vm
for each module. Though this will slow the test cycle down and only
delay the problem if it is down to the way the systests operate.
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Java] Build PermGen issues
Posted by Martin Ritchie <ri...@apache.org>.
On 4 June 2010 15:06, Andrew Kennedy <an...@gmail.com> wrote:
> On 4 June 2010 12:07, Martin Ritchie <ri...@apache.org> wrote:
>> I've been having a look at our PermGen issues.
> [...]
>> One
>> alternative would be to change our ant iterate task to fork a new vm
>> for each module. Though this will slow the test cycle down and only
>> delay the problem if it is down to the way the systests operate.
>
> We could, though, also set forkmode to once, which ought to just use
> one VM for all the tests, and shouldn't incur a large time penalty...
>
> <junit fork="yes" forkmode="once" maxmemory="${test.mem}" reloading="no"
> haltonfailure="${haltonfailure}" haltonerror="${haltonerror}"
> failureproperty="test.failures" printsummary="on" timeout="600000" >
>
> <jvmarg value="-XX:MaxPermSize=256m"/>
I believe this will cause one junit vm to be forked for each module
which is probably the best thing to do just now if we want to avoid
setting ant_opts.
Martin
> Andrew.
> --
> -- andrew d kennedy ? edinburgh : +44 7941 197 134
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [Java] Build PermGen issues
Posted by Andrew Kennedy <an...@gmail.com>.
On 4 June 2010 12:07, Martin Ritchie <ri...@apache.org> wrote:
> I've been having a look at our PermGen issues.
[...]
> One
> alternative would be to change our ant iterate task to fork a new vm
> for each module. Though this will slow the test cycle down and only
> delay the problem if it is down to the way the systests operate.
We could, though, also set forkmode to once, which ought to just use
one VM for all the tests, and shouldn't incur a large time penalty...
<junit fork="yes" forkmode="once" maxmemory="${test.mem}" reloading="no"
haltonfailure="${haltonfailure}" haltonerror="${haltonerror}"
failureproperty="test.failures" printsummary="on" timeout="600000" >
<jvmarg value="-XX:MaxPermSize=256m"/>
Andrew.
--
-- andrew d kennedy ? edinburgh : +44 7941 197 134
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org