[infinispan-issues] [JBoss JIRA] (ISPN-2372) Memory leak in AbstractJBossMarshaller

Marko Lukša (JIRA) jira-events at lists.jboss.org
Wed Oct 10 06:42:04 EDT 2012


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

Marko Lukša commented on ISPN-2372:
-----------------------------------

The main problem is we run out of memory when running the complete test suite for CapeDwarf. Previously, the caches were started lazily and there were no problems (probably because the leak was much smaller). 

I believe we start new caches for each app - Aleš knows the details regarding this.

Yes, there are multiple leaked classloaders - one for each invocation of a test. 

Are you sure the values stored inside ThreadLocal get freed when the ThreadLocal itself is not accessible anymore? I've written a simple test and it shows that the ThreadLocal is freed, but the value stored inside it is not (it's only freed when the Thread dies).




                
> Memory leak in AbstractJBossMarshaller
> --------------------------------------
>
>                 Key: ISPN-2372
>                 URL: https://issues.jboss.org/browse/ISPN-2372
>             Project: Infinispan
>          Issue Type: Bug
>    Affects Versions: 5.2.0.Beta1
>            Reporter: Marko Lukša
>            Assignee: Dan Berindei
>            Priority: Blocker
>             Fix For: 5.2.0.Final
>
>
> {{AbstractJBossMarshaller.marshallerTL}} is leaking {{PerThreadInstanceHolder}} instances. These hold a reference to {{MarshallingConfiguration}}, which indirectly holds a reference to the classloader, which of course holds a truckload of stuff.
> The cause of the leak is the fact that noone ever calls {{remove()}} on {{marshallerTL}}. 
> I've tried adding {{marshallerTL.remove()}} to {{AbstractJBossMarshaller.stop()}}, but this only removed references from JBossAS' MSC Service threads. Other threads (in my case only one thread - "http-/127.0.0.1:8080-2") are still causing the leak.
> Here's the complete path from Thread to ModuleClassLoader:
> {code}
> classes of org.jboss.modules.ModuleClassLoader
> value of java.util.Hashtable$Entry
> [4] of java.util.Hashtable$Entry[23]
> table of org.infinispan.util.Immutables$ImmutableTypedProperties
> configurationProperties of org.hibernate.search.impl.ImmutableSearchFactory
> delegate of org.hibernate.search.impl.MutableSearchFactory"
> searchFactoryImplementor of org.infinispan.query.CommandInitializer
> value of java.util.HashMap$Entry
> [0] of java.util.HashMap$Entry[4]
> table of java.util.HashMap
> commandInitializers of org.infinispan.util.ModuleProperties
> moduleProperties of org.infinispan.factories.GlobalComponentRegistry
> gcr of org.infinispan.marshall.jboss.ExternalizerTable
> objectTable of org.jboss.marshalling.MarshallingConfiguration
> configuration of org.infinispan.marshall.jboss.AbstractJBossMarshaller$PerThreadInstanceHolder
> value of java.lang.ThreadLocal$ThreadLocalMap$Entry
> [3462] of java.lang.ThreadLocal$ThreadLocalMap$Entry[4096]
> table of java.lang.ThreadLocal$ThreadLocalMap
> threadLocals of java.lang.Thread [Stack Local, Thread]  ""http-/127.0.0.1:8080-2"" native ID: 0x1B18", "28"
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the infinispan-issues mailing list