Details
-
Bug
-
Resolution: Duplicate
-
Major
-
4.0.9
-
None
Description
WildFly injects a custom thread pool into its JGroups transports.
However, in JGroups 4.0.x, only the default thread pool exposes a setThreadPool(...) method. The internal thread pool does not. However, the logic within TP.init() will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.
Can we restore the TP.setInternalThreadPool(...) method? Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when thread_pool_enabled is true?
Attachments
Issue Links
- relates to
-
JGRP-2244 Use of TP.internal_pool can result in classloader leaks
- Resolved