-
Bug
-
Resolution: Done
-
Major
-
None
-
False
-
None
-
False
-
-
-
-
-
-
-
A new ThreadGroup is created each time the DefaultExecutorFactory#getExecutor() is called:
if (blocking == null) { threadGroup = Thread.currentThread().getThreadGroup(); } else { threadGroup = Boolean.parseBoolean(blocking) ? new BlockingThreadFactory.ISPNBlockingThreadGroup(threadNamePrefix + "-group") : new NonBlockingThreadFactory.ISPNNonBlockingThreadGroup(threadNamePrefix + "-group"); } ... Thread th = new Thread(threadGroup, r, threadName);
The context of the memory leak is that during each application redeployment in Wildfly / EAP, a new instances of ISPNBlockingThreadGroup & ISPNNonBlockingThreadGroup plus some objects around those are created, and these are never cleared so they accumulate.
See JBEAP-25513 for details on how to reproduce.
Besides the fact that the ThreadGroup is never cleared up and introduces a memory leak, the group has always the same name, so it would perhaps be better to create it only once a then reuse this single instance?
Alternatively the group could maybe be discarded at some point (not sure when)?
- blocks
-
JBEAP-25573 (7.4.z) Memory leak on app redeploy
- Closed
- clones
-
ISPN-15147 DefaultExecutorFactory can create multiple ThreadGroups
- Resolved
-
JBEAP-25618 (8.0.z) ISPN-15147 DefaultExecutorFactory can create multiple ThreadGroups
- Closed
- is incorporated by
-
JBEAP-25576 (7.4.z) Upgrade Infinispan from 11.0.17.Final-redhat-00001 to 11.0.18.Final-redhat-00001
- Closed