Hi Janko,
Very nice analysis. It usually takes me a little bit to get my mind
around these problems... Could you create 2 Jira's?
Can you make your application available for testing purposes? That
would be a big help.
A few more comments, below...
On Feb 18, 2009, at 9:21 AM, Janko Heilgeist wrote:
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
$currentt...@0x2aaab33514f0)
exclude :
-->
org.apache.geronimo.transaction.manager.TransactionTimer
$currentt...@0x2aaab33514f0
(164 bytes) (field inheritedAccessControlContext:) exclude
--> java.security.accesscontrolcont...@0x2aaab27805e8 (41 bytes)
(field
context:) exclude
--> [Ljava.security.ProtectionDomain;@0x2aaab094c8f8 (144 bytes)
(Element 12 of [Ljava.security.ProtectionDomain;@0x2aaab094c8f8:)
exclude
--> java.security.protectiondom...@0x2aaab0555518 (50 bytes) (field
classloader:) exclude
-->
org
.apache.geronimo.kernel.config.multiparentclassloa...@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.
Could you attach this patch file to the Jira that you create? Clicking
the "Grant license to ASF" button gives us your permission to apply
the Apache license to your contribution.
The second issue is with the Tomcat parts of Geronimo and was not able
to completely debug this one:
--> org.apache.geronimo.tomcat.realm.tomcatjaasre...@0x2aaab10ab438
(180
bytes) (field container:) exclude
--> org.apache.geronimo.tomcat.geronimostandardcont...@0x2aaab322d390
(749 bytes) (field parentClassLoader:) exclude
-->
org
.apache.geronimo.kernel.config.multiparentclassloa...@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.childrenconfigurationclassloa...@0x2aaab05e8bc0
(115 bytes) (field parent:) exclude
-->
org
.apache.geronimo.kernel.config.multiparentclassloa...@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?
IIUC, the TomcatJAASRealm is keeping the GeronimoStandardContext (and
associated ClassLoaders) alive. So, I'd start looking at the GC roots
of the TomcatJAASRealm instance...
--kevan
