Peter.
OK, ThreadPool become a block like any other, in that there would be XML in assembly.xml and config.xml. Fine by me.
You think that a lot of "core" existing code is not using org.apache.avalon.excalibur.thread.ThreadPool and should be.
Would we have a default Phoenix/Cornerstone block that implemented thread-pool and patched it's calls through to the excalibur version? Could/should the excalibur version continue to be used directly by blocks or should everything migrate to the block based ThreadPool?
(hoping I have understood correctly).
Regards,
- Paul H
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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
