From issues at jboss.org  Mon Apr  1 07:11:03 2019
From: issues at jboss.org (=?UTF-8?Q?Adri=C3=A1n_L=C3=B3pez_=28Jira=29?=)
Date: Mon, 1 Apr 2019 07:11:03 -0400 (EDT)
Subject: [jboss-remoting-issues] [JBoss JIRA] (JBREM-1340) Memory leak
 related to org.jboss.threads.JBossThreadFactory
In-Reply-To: <JIRA.12800141.1554116894000@Atlassian.JIRA>
References: <JIRA.12800141.1554116894000@Atlassian.JIRA>
	<JIRA.12800141.1554116894922@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12800141.1554116894000.125346.1554117063155@Atlassian.JIRA>

Adri?n L?pez created JBREM-1340:
-----------------------------------

             Summary: 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


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)


From issues at jboss.org  Mon Apr  1 07:13:32 2019
From: issues at jboss.org (=?UTF-8?Q?Adri=C3=A1n_L=C3=B3pez_=28Jira=29?=)
Date: Mon, 1 Apr 2019 07:13:32 -0400 (EDT)
Subject: [jboss-remoting-issues] [JBoss JIRA] (JBREM-1340) Memory leak
 related to org.jboss.threads.JBossThreadFactory
In-Reply-To: <JIRA.12800141.1554116895000@Atlassian.JIRA>
References: <JIRA.12800141.1554116895000@Atlassian.JIRA>
	<JIRA.12800141.1554116895000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12800141.1554116895000.125813.1554117212036@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBREM-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adri?n L?pez updated JBREM-1340:
--------------------------------
    Attachment: img-2019-04-01-130952.png


> 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
>
>
> 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)


From issues at jboss.org  Mon Apr  1 07:17:04 2019
From: issues at jboss.org (=?UTF-8?Q?Adri=C3=A1n_L=C3=B3pez_=28Jira=29?=)
Date: Mon, 1 Apr 2019 07:17:04 -0400 (EDT)
Subject: [jboss-remoting-issues] [JBoss JIRA] (JBREM-1340) Memory leak
 related to org.jboss.threads.JBossThreadFactory
In-Reply-To: <JIRA.12800141.1554116895000@Atlassian.JIRA>
References: <JIRA.12800141.1554116895000@Atlassian.JIRA>
	<JIRA.12800141.1554116895000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12800141.1554116895000.125886.1554117424828@Atlassian.JIRA>


     [ 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)


From issues at jboss.org  Mon Apr  1 07:17:05 2019
From: issues at jboss.org (=?UTF-8?Q?Adri=C3=A1n_L=C3=B3pez_=28Jira=29?=)
Date: Mon, 1 Apr 2019 07:17:05 -0400 (EDT)
Subject: [jboss-remoting-issues] [JBoss JIRA] (JBREM-1340) Memory leak
 related to org.jboss.threads.JBossThreadFactory
In-Reply-To: <JIRA.12800141.1554116895000@Atlassian.JIRA>
References: <JIRA.12800141.1554116895000@Atlassian.JIRA>
	<JIRA.12800141.1554116895000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12800141.1554116895000.125889.1554117425556@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBREM-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adri?n L?pez updated JBREM-1340:
--------------------------------
    Attachment: lep2jia1-heapdump-1554113927775_Leak_Suspects.zip


> 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)


From issues at jboss.org  Mon Apr  1 07:57:02 2019
From: issues at jboss.org (David Lloyd (Jira))
Date: Mon, 1 Apr 2019 07:57:02 -0400 (EDT)
Subject: [jboss-remoting-issues] [JBoss JIRA] (JBREM-1340) Memory leak
 related to org.jboss.threads.JBossThreadFactory
In-Reply-To: <JIRA.12800141.1554116895000@Atlassian.JIRA>
References: <JIRA.12800141.1554116895000@Atlassian.JIRA>
	<JIRA.12800141.1554116895000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12800141.1554116895000.126372.1554119822298@Atlassian.JIRA>


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

David Lloyd commented on JBREM-1340:
------------------------------------

I think the problem is unbounded thread creation in the old JBoss management client.  It really seems like a problem that was fixed years ago.  You would need to upgrade your client library and configure it to connect via {{remote}} to be compatible with the old server you're using.

> 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)


From issues at jboss.org  Wed Apr  3 03:35:01 2019
From: issues at jboss.org (=?UTF-8?Q?Adri=C3=A1n_L=C3=B3pez_=28Jira=29?=)
Date: Wed, 3 Apr 2019 03:35:01 -0400 (EDT)
Subject: [jboss-remoting-issues] [JBoss JIRA] (JBREM-1340) Memory leak
 related to org.jboss.threads.JBossThreadFactory
In-Reply-To: <JIRA.12800141.1554116895000@Atlassian.JIRA>
References: <JIRA.12800141.1554116895000@Atlassian.JIRA>
	<JIRA.12800141.1554116895000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12800141.1554116895000.144547.1554276901174@Atlassian.JIRA>


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

Adri?n L?pez commented on JBREM-1340:
-------------------------------------

Where can I find some doc to know how to configure the new client with the "old" remoting?
Kinda los with this protocol and its transports.
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)