[jboss-jira] [JBoss JIRA] (JGRP-1410) globalThreadGroup not destroyed creates a classloader memory leak

Sei Syvalta (JIRA) jira-events at lists.jboss.org
Wed Jan 25 10:51:51 EST 2012


    [ https://issues.jboss.org/browse/JGRP-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661921#comment-12661921 ] 

Sei Syvalta commented on JGRP-1410:
-----------------------------------

When org.jgroups.util.GLOBAL_GROUP is created, constructor which uses default parent is used. The parent adds reference to this new ThreadGroup GLOBAL_GROUP. From this anonymous ThreadGroup there's reference to the ClassLoader which jgroups is loaded by. In this case it is the web application class loader which means the class loader is strongly reachable and cannot be collected.

Dump from jhat:
--> java.lang.ThreadGroup at 0x9891ff8 (43 bytes) (field groups:)
--> [Ljava.lang.ThreadGroup;@0x9b86648 (24 bytes) (Element 2 of [Ljava.lang.ThreadGroup;@0x9b86648:)
--> org.jgroups.util.Util$1 at 0xd3560e8 (43 bytes) (??:)
--> class org.jgroups.util.Util$1 (84 bytes) (??:)
--> weblogic.utils.classloaders.ChangeAwareClassLoader at 0xbe8cca0 (89 bytes)

Calling destroy() for the ThreadGroup should fix the issue, as proposed by the original reporter (it removes the reference from parent).
                
> globalThreadGroup not destroyed creates a classloader memory leak
> -----------------------------------------------------------------
>
>                 Key: JGRP-1410
>                 URL: https://issues.jboss.org/browse/JGRP-1410
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.0.1
>         Environment: linux w/ java 1.6
>            Reporter: Jean-Philippe Gariepy
>            Assignee: Bela Ban
>             Fix For: 3.1
>
>
> When all channels are closed, the globalThreadGroup is not destroyed.  For a normal (i.e. non-web) application, this is not a problem since the process will exit anyway.  However, for a Java Enterprise web application, this causes a classloader memory leak since the ThreadGroup object has strong references to JGroups instances having strong references to their class object having strong reference to their class loader.  Since the class loader is pointed by strong references, the it cannot be garbage collected and hence a leak is created each time the web application is stopped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the jboss-jira mailing list