Re: PermGen OutOfMemory, JRuby 1.2.0

On Thu, Jun 25, 2009 at 11:41 AM, Jacob Kessler<Jacob.Kessler@...> wrote:
> From the GlassFish end of things, we've noticed three things that cause
> this.

Excellent, thanks for sounding off on this issue Jacob!

> The first is Grizzly caching Request objects in thread local. While that's
> good for performance reasons, it ends up meaning that a reference to the
> JRuby runtime will stick around until the cache is cleared. There should be
> a fix in the next released version of GlassFish (both gem and server), and
> in the mean time you can "manually" clear the cache by sending several
> requests to the server after undeploy, such as to a non-existent
> contextroot.

Does this "manual clear" need to occur after the un-deploy but before
the subsequent deploy of the app?

> We've also seen some issues around JRuby unregistering itself as a secure
> communications provider (through JRuby-openssl). Similarly, that ends up
> keeping a reference to a JRuby runtime, so that things aren't collected. I
> know that the JRuby people are working on getting a fix together for that,
> in the mean time the default JRuby limited openssl doesn't seem to have this
> issue.

In my case I am using the "limited openssl" option so I don't think
this one is effecting me.

> Lastly, there is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990
> , which likely affects all of the listed application servers. As mentioned
> in the bug, increasing permgen size (while having class unloading enabled)
> will cause correct behavior and no leak. I'm working with one of the JDK
> team members to get a fix for this finally integrated into the JDK.

Do I need to go out of my way to enable class unloading?  Is there a
special JVM option that forces this feature to be enabled?

> Tomcat and JBoss may have other, or additional, causes of permgen leakage. I
> haven't looked into this using them, so I can't provide much information
> there.

Thanks!
-CJ

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email