[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=12725501#comment-12725501 ] 

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

Marko, I misread your comment and I understood that the value of the ThreadLocal will be removed from the table when any other ThreadLocal is put in the table... I'm not sure why the implementation doesn't use reference queues to free the values the moment the keys are GCed, but this way I guess it's possible for the ThreadLocalTable to grow such that some entries are never overwritten and the classloader is never GCed.

I have two more questions:
1. Have you tried my branch, and does it make any difference in your CapeDwarf tests?
2. Is the path you posted in the JIRA description the only path from PerThreadInstanceHolder to ModuleClassLoader, or is it just the shortest one? If it's the only path, it may be worth cleaning the list of command initializers on cache manager shutdown.
                
> 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