-
Bug
-
Resolution: Done
-
Critical
-
7.4.12.GA, 8.0.0.GA-CR1
-
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-25513 (8.0.z) Memory leak on app redeploy
- Closed
- clones
-
ISPN-15147 DefaultExecutorFactory can create multiple ThreadGroups
- Resolved
- is cloned by
-
JBEAP-25617 (7.4.z) ISPN-15147 - DefaultExecutorFactory can create multiple ThreadGroups
- Closed
- is incorporated by
-
JBEAP-25194 (8.0.z) Upgrade Infinispan to 14.0.17.Final
- Closed
- relates to
-
JBEAP-26212 (8.0.z) ISPN-15368 - Eliminate repeatedly created ThreadGroups
- Closed