11:26 p.m.
Marko Lukša created ISPN-2372:
---------------------------------
Summary: 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: Mircea Markus
{{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
5:17 a.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Ales Justin updated ISPN-2372:
------------------------------
Priority: Blocker (was: Major)
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: Mircea Markus
Priority: Blocker
{{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
7:53 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Mircea Markus updated ISPN-2372:
--------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
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
7:53 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Mircea Markus updated ISPN-2372:
--------------------------------
Fix Version/s: 5.2.0.Final
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
6:13 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-2372:
------------------------------------
Normally you shouldn't need to call {{marshallerTL.remove()}} at all, once the
{{AbstractJBossMarshaller}} instance is no longer referenced by the cache all the
thread-locals should be freed by the GC.
It looks like there's a back-reference from {{PerThreadInstanceHolder}} to
{{AbstractJBossMarshaller}}, or maybe someone else is holding the
{{AbstractJBossMarshaller}} instance alive. Can you check this with a heap dump, or attach
a heap dump to the bug report?
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
6:17 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-2372:
------------------------------------
I haven't found the cycle between {{AbstractJBossMarshaller}} and
{{PerThreadInstanceHolder}}, but I modified AJBM to break the cycle on {{stop()}} anyway.
Since I don't know exactly what the root cause is I'm not issuing a pull req yet,
but you can pull my branch at https://github.com/danberindei/infinispan/tree/t_2372_m and
see if it makes any difference for you.
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
6:19 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Work on ISPN-2372 started by Dan Berindei.
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
7:18 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Dan Berindei commented on ISPN-2372:
------------------------------------
Marko, can you also add more details on your scenario? E.g. is your problem that the
classloader is not released on undeploy? do you have a cache manager per app, or is only
the cache per app? when you deploy and undeploy multiple times, do you see multiple leaked
classloaders or just the first one?
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
7:42 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
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
7:44 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Marko Lukša updated ISPN-2372:
------------------------------
Attachment: ThreadLocalTest.java
Attaching ThreadLocalTest.java
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
8:05 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Marko Lukša commented on ISPN-2372:
-----------------------------------
Ah, I see. The values of the ThreadLocals are freed eventually - but only when two things
occur:
1. the GC runs and clears the WeakReference to ThreadLocal
2. another ThreadLocal is stored in its place in Thread.threadLocals.table
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
8:42 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Ales Justin commented on ISPN-2372:
-----------------------------------
> I believe we start new caches for each app - Aleš knows the
details regarding this.
We actually start 8 caches for each app.
They need to be eager started, so any M/R tasks, jobs work as expected; see ISPN-2353.
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
10:57 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
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
4:28 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
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
7:03 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Ales Justin commented on ISPN-2372:
-----------------------------------
This stop() change is just a temp fix, as it will only clear things on undeploy /
shutdown,
which is very rare in real production apps -- meanwhile memory will leak all the time,
with every request.
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
8:07 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Marko Lukša updated ISPN-2372:
------------------------------
Attachment: paths.txt
Dan, yes, your patch does seem to alleviate the problem - the complete test suite runs
without running out of memory.
After running the whole testsuite, there are approx 15 leaked references to the
classloader. I'm attaching paths.txt, which contains the paths to one of them.
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: paths.txt, 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
8 p.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Dan Berindei updated ISPN-2372:
-------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1384
I found a way to clear the ExternalizerTable reference in all the threads at once, by
using a proxy.
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: paths.txt, 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
4:33 a.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Adrian Nistor updated ISPN-2372:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated.
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: paths.txt, 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
4:35 a.m.
[
https://issues.jboss.org/browse/ISPN-2372?page=com.atlassian.jira.plugin....
]
Adrian Nistor updated ISPN-2372:
--------------------------------
Fix Version/s: 5.2.0.CR1
(was: 5.2.0.Final)
Git Pull Request: https://github.com/infinispan/infinispan/pull/1384 (was:
https://github.com/infinispan/infinispan/pull/1384)
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.CR1
Attachments: paths.txt, 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
4235
days inactive
4239
days old
infinispan-issues@lists.jboss.org
18 comments
5 participants
participants (5)
-
Adrian Nistor (JIRA) -
Ales Justin (JIRA)
-
Dan Berindei (JIRA)
-
Marko Lukša (JIRA)
-
Mircea Markus (JIRA)