[jboss-remoting-issues] [JBoss JIRA] (JBREM-1340) Memory leak related to org.jboss.threads.JBossThreadFactory

[ https://issues.jboss.org/browse/JBREM-1340?page=com.atlassian.jira.plugin... ] 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 -- This message was sent by Atlassian Jira (v7.12.1#712002)