[
https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin....
]
Brian Stansberry commented on REMJMX-94:
----------------------------------------
Brad, WFCORE-553 sounds different from the description of this JIRA. The description
describes what sounds like a classloader leak in the client. WFCORE-553 is a server side
problem with inefficient cleanup of server thread pools, such that the number of file
descriptors used by the server is excessive if the pace of opening and closing remoting
management channels outpaces the gc. It's more a problem that a load test fixture like
your reproducer for
https://bugzilla.redhat.com/show_bug.cgi?id=1193926 would hit.
Memory leak in remoting-jmx
---------------------------
Key: REMJMX-94
URL:
https://issues.jboss.org/browse/REMJMX-94
Project: Remoting JMX
Issue Type: Bug
Affects Versions: 1.1.3.Final
Reporter: Libor Zoubek
Assignee: Darran Lofthouse
Labels: memory_leak
In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx.
Leak is very notable once we restart our plugin container (each plugin has in it's own
classloader) Classes owned by RHQ Server plugin don't get GCed.
I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating
following steps:
1. start new thread
2. assign URL classloader to this thread (point it to jboss-client.jar)
3. connect & disconnect to jmx-remoting endpoint
In this test no classes don't get GCed which after serveral iterations ends up in
OOM.
My test/example is here
https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org...
I am not sure if memleak is in remoting-jmx or some other underlying stuff.
I thought
https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned
does not help.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)