Hi,
I have been hacking at trying to figure out how best to handle thread
management for applications. I have tried about 5 models and all led to
ugliness. Ages ago Avalon/Phoenix used to manage thread pools via another
Block.
However we/I decided that threads were in the same category as other "system"
level services (like ClassLoader/security/logging etc). However if you look
how it is actually used you will notice that most blocks do not use the
thread pool and just construct new threads via
new Thread( myRunnable ).start()
or similar. While I still think threads are inherently a system-level service
I now think that thread-pools are a service that should be offered at Block
level.
So what I am proposing is that the functionality is split up more. The
setting of thread level "context"* and starting top-level ThreadGroup would
be considered "system"-level while ThreadPools would be accessed via a Block.
To maintain backwards compatability the mechanisms currently in place (ie set
threads via server.xml) will stay in place but be deprecated.
Thoughts?
* thread level "context" refers to information that must be associated with a
thread for some reason or another. Examples include ContextClassLoader,
Security Subject/Principle, Maybe application name etc.
--
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
