[ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2246: --------------------------- 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? was: 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? -- This message was sent by Atlassian JIRA (v7.5.0#75005)