geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janko Heilgeist <janko...@dalighe.de>
Subject PermGen space issues
Date Wed, 18 Feb 2009 14:21:07 GMT
Hi,

I am currently debugging an EAR that isn't correctly undeployed. I
noticed in jconsole that the classes loaded during deployment are never
GCed after undeployment. Playing around with jmap and jhat I discovered
two places where IMHO something's amiss in Geronimo. I've never done
this kind of debugging before so please tell me if I am wrong ;-)

The first issue is in the component geronimo-transaction:

Java Local Reference (from
org.apache.geronimo.transaction.manager.TransactionTimer$CurrentTime@0x2aaab33514f0)
exclude  :
-->
org.apache.geronimo.transaction.manager.TransactionTimer$CurrentTime@0x2aaab33514f0
(164 bytes) (field inheritedAccessControlContext:) exclude
--> java.security.AccessControlContext@0x2aaab27805e8 (41 bytes) (field
context:) exclude
--> [Ljava.security.ProtectionDomain;@0x2aaab094c8f8 (144 bytes)
(Element 12 of [Ljava.security.ProtectionDomain;@0x2aaab094c8f8:) exclude
--> java.security.ProtectionDomain@0x2aaab0555518 (50 bytes) (field
classloader:) exclude
-->
org.apache.geronimo.kernel.config.MultiParentClassLoader@0x2aaab1c15600
(156 bytes) exclude

A similar problem came up in the JBoss forum with an IdleRemover thread:

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=74904

>From what I've pieced together from this and other sources, it looks to
me like the CurrentTime thread should be started in a privileged block
to prevent it from inheriting the AccessControlContext of my EAR. I've
attached a patch that works for me but YMMV.

The second issue is with the Tomcat parts of Geronimo and was not able
to completely debug this one:

--> org.apache.geronimo.tomcat.realm.TomcatJAASRealm@0x2aaab10ab438 (180
bytes)  (field container:) exclude
--> org.apache.geronimo.tomcat.GeronimoStandardContext@0x2aaab322d390
(749 bytes) (field parentClassLoader:) exclude
-->
org.apache.geronimo.kernel.config.MultiParentClassLoader@0x2aaab2e9b2e0
(156 bytes) (field parents:) exclude
--> [Ljava.lang.ClassLoader;@0x2aaab0b97958 (88 bytes) (Element 1 of
[Ljava.lang.ClassLoader;@0x2aaab0b97958:) exclude
-->
org.apache.geronimo.kernel.config.ChildrenConfigurationClassLoader@0x2aaab05e8bc0
(115 bytes) (field parent:) exclude
-->
org.apache.geronimo.kernel.config.MultiParentClassLoader@0x2aaab2e9b230
(156 bytes) exclude

Here, the last MultiParentClassLoader corresponds to the EAR and the one
in the middle belongs to the WAR inside the EAR. The
GeronimoStandardContext belongs to the WAR, too. It look to me like the
bi-directional reference between the TomcatJAASRealm and the
GeronimoStandardContext keeps the EAR's classloader from being GCed.

Any hints on what I can do to exactly locate this issue?

Janko

Mime
View raw message