[jboss-dev] New thread management in appserver deployments

[David M. Lloyd]

Since 5.1.0.Beta1, there is a new way to define thread pools, thread 
factories, and other thread-related stuff.  If you've got a service 
(especially a POJO-ized service) that is deployed in the AS, I recommend 
that you have a look at migrating your deployment to use this new mechanism.

The project is called JBoss Threads, and there's a bug tracker for it here: 
https://jira.jboss.org/jira/secure/project/ViewProject.jspa?pid=12310786

The idea is that you can declare a thread pool in your service deployment 
descriptor, and then you can inject this thread pool as an Executor into a 
managed bean, sort of like this example jboss-beans.xml file:

    <deployment xmlns="urn:jboss:bean-deployer:2.0">

        <threads xmlns="urn:jboss:threads:1.0">
            <thread-group name="MyThreadGroup" group-name="mine"/>

            <thread-factory name="MyThreadFactory" group="MyThreadGroup" 
thread-name-pattern="my-pool%f-%t"/>

            <thread-pool-executor name="MyExecutor" 
thread-factory="MyThreadFactory" allow-core-timeout="true" queue-length="50">
                <core-pool-size count="5"/>
                <max-pool-size count="10" per-cpu="2"/>
                <keepalive-time time="10" unit="seconds"/>
                <reject-policy name="block"/>
            </thread-pool-executor>
        </threads>

        <bean class="your.bean.Class">
            <property name="executor">
                <inject bean="MyExecutor"/>
            </property>
        </bean>
    </deployment>

This example makes a thread pool executor that has no threads until tasks 
are submitted, and keeps idle threads around for 10 seconds before cleaning 
them up.  The pool will not grow larger than 10 threads plus 2 threads per 
detected CPU.

If your component already expects an injected Executor, then this should be 
a trivial change to make.  This implementation does not implement the older 
ThreadPool-related interfaces from jboss-common-core.  My personal 
inclination is to leave it off and migrate to a fully Executor-based 
system.  Things that require functionality only provided by the older API 
could perhaps still be accomodated by some kind of wrapper mechanism, if 
necessary.

There are some todo items, like developing a mechanism to automatically 
propagate relevant contextual information from the executing thread to the 
executor thread (including but not limited to the thread context class 
loader).  I'd like to develop a more generic mechanism though (the idea 
being that the average user can inject an Executor to use from any old 
deployment, and everything that can just magically work, will).  Ideas are 
welcome. :-)  Also, there is no JMX management view yet (this is a TODO for 
CR1).

The advantage to this model is that implementation details (class name, 
property names) of the thread pool are no longer specified in the 
deployment descriptor, which means that the class can change under certain 
circumstances (in fact, the class is already substituted when there are 
parameter combinations which are not supported by the standard 
ThreadPoolExecutor).  This is a model I hope that we can continue to move 
towards.

- DML