This is in response to a few related JIRAs: JBCACHE-1262 JBCACHE-1268 JBCACHE-1108 There are other internal service threads as well, such as async cache loader writer threads, repl queue threads, etc. WRT. the JIRAs above, it makes sense to refactor these to use an ExecutorService and then allow users to pass in their own ExecutorService, either via an ExecutorServiceProvider interface, or by using a setter on the Configuration (for IOC frameworks). This would default to a fixed pool service using a single thread, except for the case of JBCACHE-1262 and JBCACHE-1108 where it may make sense to allow users to configure a pool size. Now my question is this - how much flexibility would people want? Does it make sense to use a single ExecutorService for all such service tasks? Or does it make sense for this to be more fine-grained? Brian, this would be related to your use case of not using the internal eviction thread for SFSB state. Perhaps what we need is a decoupling between the executors themselves and the tasks they are used for - e.g., | <executors> | <executor name="evictionExecutor"> | <pool size="1" /> | <async /> | </executor> | <executor name="genericExecutor"> | <lookupClass>com.company.MyAppExecutorProvider</> | </executor> | </executors> | | ... | | <eviction> | <executor name="evictionExecutor" /> | ... | </eviction> | | ... | | <notifications> | <executor name="genericExecutor" /> | </notifications> | | <replication> | <async> | <executor name="genericExecutor" /> | </async> | ... | </replication> | ... | Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164568#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...