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

[Dan Berindei (JIRA)]

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

Dan Berindei commented on ISPN-2372:
------------------------------------

Marko, yes, I knew that the thread locals are cleared eventually but I didn't know exactly how it happens. I think this should be enough for your tests - eventually each worker thread either dies or receives a new request that accesses the new cache and puts the new marshaller, and at some point you will have 0 references to the old classloader.

I'd still like to know how we got a reference from the {{PerThreadInstanceHolder}} back to the {{AbstractJBossMarshaller}}, especially after the cache was stopped and the volatile components were deleted from the component registry - it might help to replace some of the links there with {{WeakReference}}s.
                
> 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
>
>         Attachments: ThreadLocalTest.java
>
>
> {{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