[jboss-remoting-issues] [JBoss JIRA] (JBREM-1340) Memory leak related to org.jboss.threads.JBossThreadFactory
Adrián López (Jira)
issues at jboss.org
Mon Apr 1 07:17:04 EDT 2019
[ https://issues.jboss.org/browse/JBREM-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adrián López updated JBREM-1340:
--------------------------------
Description:
We have a memory leak when using the jboss-cli-client JAR inside of Jolokia.
Jolokia uses remoting to connect to the JMX of several JBoss servers. After running for some days, the Old Gen memory space reach 100%.
A heap dump analyzed with Eclipse MAT returns:
{code}
One instance of "java.lang.ThreadGroup" loaded by "<system class loader>" occupies 377.517.248 (87,28%) bytes. The instance is referenced by org.jboss.threads.JBossThread @ 0xe0a81ef0 HTTP-11 , loaded by "org.jboss.modules.ModuleClassLoader @ 0xe04ffe20". The memory is accumulated in one instance of "java.lang.ThreadGroup[]" loaded by "<system class loader>".
The stacktrace of this Thread is available. See stacktrace.
Keywords
java.lang.ThreadGroup[]
org.jboss.modules.ModuleClassLoader @ 0xe04ffe20
java.lang.ThreadGroup
{code}
Thread stack
{code}
HTTP-11
at sun.misc.Unsafe.park(ZJ)V (Native Method)
at java.util.concurrent.locks.LockSupport.park(Ljava/lang/Object;)V (LockSupport.java:186)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()V (AbstractQueuedSynchronizer.java:2043)
at java.util.concurrent.LinkedBlockingQueue.take()Ljava/lang/Object; (LinkedBlockingQueue.java:442)
at java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable; (ThreadPoolExecutor.java:1068)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (ThreadPoolExecutor.java:1130)
at java.util.concurrent.ThreadPoolExecutor$Worker.run()V (ThreadPoolExecutor.java:615)
at java.lang.Thread.run()V (Thread.java:745)
at org.jboss.threads.JBossThread.run()V (JBossThread.java:122)
{code}
I have created also another [issue|https://issues.jboss.org/browse/JBTHR-72] to jboss-threads, but looks the problem is not there.
Same for [Jolokia|https://github.com/rhuss/jolokia/issues/401]
Thanks
was:
We have a memory leak when using the jboss-cli-client JAR inside of Jolokia.
Jolokia uses remoting to connect to the JMX of several JBoss servers. After running for some days, the Old Gen memory space reach 100%.
A heap dump analyzed with Eclipse MAT returns:
{code}
One instance of "java.lang.ThreadGroup" loaded by "<system class loader>" occupies 377.517.248 (87,28%) bytes. The instance is referenced by org.jboss.threads.JBossThread @ 0xe0a81ef0 HTTP-11 , loaded by "org.jboss.modules.ModuleClassLoader @ 0xe04ffe20". The memory is accumulated in one instance of "java.lang.ThreadGroup[]" loaded by "<system class loader>".
The stacktrace of this Thread is available. See stacktrace.
Keywords
java.lang.ThreadGroup[]
org.jboss.modules.ModuleClassLoader @ 0xe04ffe20
java.lang.ThreadGroup
{code}
I have created also another [issue|https://issues.jboss.org/browse/JBTHR-72] to jboss-threads, but looks the problem is not there.
Same for [Jolokia|https://github.com/rhuss/jolokia/issues/401]
Thanks
> Memory leak related to org.jboss.threads.JBossThreadFactory
> -----------------------------------------------------------
>
> Key: JBREM-1340
> URL: https://issues.jboss.org/browse/JBREM-1340
> Project: JBoss Remoting
> Issue Type: Bug
> Components: jmx remoting
> Reporter: Adrián López
> Priority: Major
> Attachments: img-2019-04-01-130952.png, lep2jia1-heapdump-1554113927775_Leak_Suspects.zip
>
>
> We have a memory leak when using the jboss-cli-client JAR inside of Jolokia.
> Jolokia uses remoting to connect to the JMX of several JBoss servers. After running for some days, the Old Gen memory space reach 100%.
> A heap dump analyzed with Eclipse MAT returns:
> {code}
> One instance of "java.lang.ThreadGroup" loaded by "<system class loader>" occupies 377.517.248 (87,28%) bytes. The instance is referenced by org.jboss.threads.JBossThread @ 0xe0a81ef0 HTTP-11 , loaded by "org.jboss.modules.ModuleClassLoader @ 0xe04ffe20". The memory is accumulated in one instance of "java.lang.ThreadGroup[]" loaded by "<system class loader>".
> The stacktrace of this Thread is available. See stacktrace.
> Keywords
> java.lang.ThreadGroup[]
> org.jboss.modules.ModuleClassLoader @ 0xe04ffe20
> java.lang.ThreadGroup
> {code}
> Thread stack
> {code}
> HTTP-11
> at sun.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park(Ljava/lang/Object;)V (LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()V (AbstractQueuedSynchronizer.java:2043)
> at java.util.concurrent.LinkedBlockingQueue.take()Ljava/lang/Object; (LinkedBlockingQueue.java:442)
> at java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable; (ThreadPoolExecutor.java:1068)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (ThreadPoolExecutor.java:1130)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run()V (ThreadPoolExecutor.java:615)
> at java.lang.Thread.run()V (Thread.java:745)
> at org.jboss.threads.JBossThread.run()V (JBossThread.java:122)
> {code}
> I have created also another [issue|https://issues.jboss.org/browse/JBTHR-72] to jboss-threads, but looks the problem is not there.
> Same for [Jolokia|https://github.com/rhuss/jolokia/issues/401]
> Thanks
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
More information about the jboss-remoting-issues
mailing list