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]
