There was some talk on #jboss-dev about using an executor in the controller during bootstrap and then to avoid having too many thread pools configured to replace that with the system thread pool once that is installed. Assuming that the system thread pool in AS trunk is the one deployed in thread-pool-jboss-beans.xml: | <!-- Basic system thread pool deployment --> | <deployment xmlns="urn:jboss:bean-deployer:2.0"> | | <threads xmlns="urn:jboss:threads:1.0"> | <thread-group name="SystemThreadFactoryGroup" group-name="System Threads"/> | <thread-factory name="SystemThreadFactory" group="SystemThreadFactoryGroup"/> | | <!-- | ~ This thread pool is for SHORT-RUNNING tasks that block very little or not at all. Long-running | ~ tasks submitted to this pool may cause starvation and extended blocking. | --> | <thread-pool-executor name="ThreadPool" thread-factory="SystemThreadFactory" queue-length="1000"> | <core-pool-size count="5" per-cpu="2"/> | <max-pool-size count="10" per-cpu="3"/> | <keepalive-time time="30" unit="seconds"/> | <reject-policy name="block"/> | </thread-pool-executor> | </threads> | </deployment> | I don't think this pool will work for the controller if my understanding of | <reject-policy name="block"/> | is correct (that the caller blocks until a thread is available). The behaviour of the controller is to try to deploy asynchronous contexts via the executor, but if the executor is full to deploy the context in the calling thread. So I need a reject policy that behaves like ThreadPoolExecutor.AbortPolicy or ThreadPoolExecutor.CallerRunsPolicy for the pool handling asynchronous deployments. So we have the choice of reusing the system thread pool but potentially blocking on asynchronous contexts (which I think kind of defeats the purpose), or having a small thread pool dedicated to deploying asynchronous contexts. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242133#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...