[Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i
by 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
17 years, 5 months
[Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i
by adrian@jboss.org
"david.lloyd(a)jboss.com" wrote :
| "adrian(a)jboss.org" wrote : But there are also some different policies such as MinThreadPoolExecutor so you can avoid the known race condition if you implement a WAIT policy when the thread pool is full (something that is not part of java.util.concurrent because of the race condition)
|
| I saw the code and the comment to that effect, but at first glance it wasn't clear what the race condition was, or how the fix worked. I'll have to look at that one more time...
The issue comes with small thread pools. e.g. a singleton MDB configuration
has a thread pool size of 1
Depending upon the reaping policy of unused threads it is possible for a race
condition to go something like this (I'll assume no queue although it makes
no real difference in practice since the race would still happen after dequeuing):
1) Thread 1: Submit work to the pool
2) Thread 2: Execute the work
3) Thread 2: Complete work
4) Thread 1: Submit some work - pool is busy so wait
5) Thread 2: Return thread to the pool
6) // CPU starvation for longer the idle time of threads
7) Thread 1: Stop waiting and check we have enough threads (we do)
8) Thread 2: I've been idle too long so end
So you end up with thread 1 thinking there are enough threads
to execute the work, but Thread 2 has stopped an instant after the check.
The work will never be executed unless some other thread also tries
to execute some work on the pool (meaning the number of threads gets rechecked).
For a singleton MDB with a read-ahead of messages of size 1 this never occurs
so message delivery to the MDB stalls.
The fix/work around we have is to stop step (8) from occuring.
i.e. you never allow the thread pool to go below a minimum of one thread
which avoids the race condition - there is always at least one thread
available to execute the work.
The real fix would be to make the check in step (7) more atomic
i.e. move the thread pool size check to later when it tries to execute the work
but that's not easy to do if you look at the code. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187346#4187346
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187346
17 years, 5 months
[Design the new POJO MicroContainer] - Re: Declaration and deployment of threads and thread pools i
by david.lloyd@jboss.com
"adrian(a)jboss.org" wrote : Why are you using float for thread priority?
| A thread can only take an integer priority between
| 1 (Thread.MIN_PRIORiTY) and 10 (Thread.MAX_PRIORITY)
I got the notion in my head that MAX_PRIORITY might not be 10, so my thought was to take a float between 1.0 and 10.0 inclusive and scale it between MIN and MAX. Though I guess I overthought it, since if someone decided to arbitrarily change the priority scale, there would probably be compatibility issues, so that would seem to be a rather unlikely scenario.
"adrian(a)jboss.org" wrote : Even if it was a decimal, BigDecimal would be better than float because of the rounding errors.
I doubt that someone would care if their thread at priority 10.1 was really running at 10.099999999999999644728632119950, since it would very likely end up being the same priority value anyway :-)
In any case, making this a float was probably a dumb idea - I think I'll just make it an int.
"adrian(a)jboss.org" wrote : But there are also some different policies such as MinThreadPoolExecutor so you can avoid the known race condition if you implement a WAIT policy when the thread pool is full (something that is not part of java.util.concurrent because of the race condition)
I saw the code and the comment to that effect, but at first glance it wasn't clear what the race condition was, or how the fix worked. I'll have to look at that one more time...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4187342#4187342
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4187342
17 years, 5 months