karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Jongsma <jer...@barchart.com>
Subject Re: karaf PermGen space problem
Date Tue, 11 Mar 2014 23:06:50 GMT
For us the cause was frequently third party libraries doing silly things
like starting non-daemon threads in static scope that cannot be shut down,
which keeps references to the old classloader. So every time that bundle is
replaced the PermGen climbs and can never be reclaimed.

Among others, the AWS SDK was a big culprit in our apps. After spending
days in the heap analyzer trying to track everything down I finally said
screw it, and now we're back to forcing a full restart w/ cache wipe when
we deploy code updates.

I don't think that hot-deployment is worth the time it will take you unless
you don't use any third party code, and even then you will regularly spend
hours in the profiler trying to figure out what's hanging onto the old
classloader with the latest code update.

On Tue, Mar 11, 2014 at 1:46 PM, Guillaume Nodet <gnodet@apache.org> wrote:

> This could also be caused by bad bundles that don't clean things correctly
> when stopped.
> 2014-03-11 19:21 GMT+01:00 Henryk Konsek <hekonsek@gmail.com>:
> Hi,
>> > If
>> > this issue exists, can we not be safe in planning to do updates like
>> that?
>> Oracle JVM keeps classes forever until instructed otherwise. Try to
>> enable garbage collector on PermGen memory space.
>> -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled
>> -XX:+CMSClassUnloadingEnabled
>> Cheers.
>> --
>> Henryk Konsek
>> http://henryk-konsek.blogspot.com

View raw message