[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i

[david.lloyd@jboss.com]

"alesj" wrote : Nice!
  | 
  | But I guess you should provide some examples.
  | e.g. few xml snippets, explaining what does what

OK, it's pretty straightforward.  Basically if you have a pojo component that requires an executor, you can build it declaratively via XML (imagine a security manager scenario - by building your executor this way, your code needs no special thread-control permissions).

So to create a thread pool for my application which keeps from 2 + 1.2n to 4 + 2n threads (where n = # of CPUs), with a bounded queue and a blocking reject-policy, I would just add a jboss-threads.xml file like this:

<threads xmlns="urn:jboss:threads:1.0">
  |     <thread-group name="MyThreadGroup" group-name="my-app" daemon="false"/>
  |     <thread-factory name="MyThreadFactory" group="MyThreadGroup"/>
  |     <thread-pool-executor name="MyExecutor" thread-factory="MyThreadFactory">
  |         <core-pool-size count="2" per-cpu="1.2"/>
  |         <max-pool-size count="4" per-cpu="2"/>
  |         <bounded-queue size="50"/>
  |         <reject-policy name="block"/>
  |     </thread-pool-executor>
  | </threads>

This makes an injectable bean called "MyExecutor" which I can add to my application using the normal mechanisms.

Alternately I could "borrow" a thread pool executor declared elsewhere, with a hook so that it changes the thread's name when it's running one of my tasks:

<threads>
  |     <notating-executor name="MyExecutor" parent="SomeOtherExecutor" note="Running my task"/>
  | </threads>

There are three different queue types available (bounded, unbounded, and direct), a variety of reject-policies, and pluggable interrupt and exception handlers.

One thing I did not (yet) account for is a facility to propagate various thread context information to tasks (things like a context classloader, security context, transaction context, etc).  I imagine some kind of pluggable system where a context type can be registered with code that knows how to get context from one thread and put context to a new thread.  Then it's just a question of adding a plugin for each context type, and new services which keep a thread context could just be registered.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187351#4187351

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187351