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]