geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: PermGen space issues
Date Wed, 18 Feb 2009 16:24:27 GMT
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 
> $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.

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.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?

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
Mime
View raw message