Out of PermGen space is almost always caused by a classloader leak which
occurs when a webapp is reloaded. It could be caused by either your own
code, third-party code, or in some case Java core classes.
You need to take heap dumps before and after webapp reload and use a heap
analyzer to see what is holding onto the leaked classloader(s).
On Tue, Apr 24, 2012 at 5:41 PM, Chris Pratt <thechrispr...@gmail.com>wrote:
> Well, yes and no. As I understand the problem, it really got bad around
> the Java 5 timeframe because of the addition of Enumerations to the
> language. What Resin does (and all auto-reloading Java containers do) is
> to create a ClassLoader that contains all the code for your application.
> When it senses a change to your code, it loads that new code into a brand
> new ClassLoader and releases the old one to be garbage collected once it's
> done processing it's active requests. The problem is that, since
> Enumerations are guaranteed to work with the == operator, even when
> serialized/deserialized between different computers, Java treats them
> special, by keeping them in the Permanent Generation (so their internal
> ID's won't change). Unfortunately, each time the app is loaded a new set
> of Enumerations takes up more space in the precious PermGen until it
> finally blows its lid. So, theoretically, you could use less PermGen by
> limiting Enumeration use, but that's really not a realistic response.
> Before Java became property of Oracle, there was some talk about fixing
> this problem at the JVM level, but I haven't heard anything in quite a
> On Tue, Apr 24, 2012 at 1:54 PM, Rick Mann <rm...@latencyzero.com> wrote:
>> When I'm making changes to the code of a webapp, Resin kindly reloads it
>> for me. I can usually get a handful of reloads in before Resin complains
>> about being out of PermGen space.
>> Is there something I'm doing wrong in my app that it leaks like this?
>> resin-interest mailing list
> resin-interest mailing list
resin-interest mailing list