You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/09/06 04:04:23 UTC
[phoenix] ThreadManager - a block or a system level service?
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] ThreadManager - a block or a system level service?
Posted by Peter Donald <do...@apache.org>.
On Thu, 6 Sep 2001 19:00, Paul Hammant wrote:
> I'm intrigued. You see multiple implementations of threadpool don't you..
Yep ... or more likely extended implementations. One may be SimpleThreadPool,
ContextManagingThreadPool, ExternallyManageableThreadPool etc.
SimpleThreadPool would be basically what we have now with perhaps a few
enhancements.
ContextManagingThreadPool would manage all thread sensitive data (like
ContextClassLoader etc) and is really only applicable when running inside
Application servers.
ExternallyManageableThreadPool would allow external managment via
SNMP/RMI/other.
Most people will use SimpleThreadPool unless they are inside Phoenix or
another ApplicationServer.
--
Cheers,
Pete
*----------------------------------------------------------*
The phrase "computer literate user" really means the person
has been hurt so many times that the scar tissue is thick
enough so he no longer feels the pain.
-- Alan Cooper, The Inmates are Running the Asylum
*----------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] ThreadManager - a block or a system level service?
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>Can you make it a simple Component instead of a Block?
>
Or Block, that wraps Component, that wraps the excalibur/scratchpad version?
-PH
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] ThreadManager - a block or a system level service?
Posted by Berin Loritsch <bl...@apache.org>.
Paul Hammant wrote:
>
> >
> >
> >For the moment but the long-term strategy would be to move everything to use
> >block directly rather than ThreadContext.getThreadPool(). The main reason is
> >because that matches how we use it and it would be easier to manage
> >performance characteristerics of pool that way.
> >
> I'm intrigued. You see multiple implementations of threadpool don't you..
Can you make it a simple Component instead of a Block?
I want to be able to use the Thread Pooling in places where Blocks can't be
compiled/used. For instance, Cocoon has a few locations where it spawns a
background thread--that really should be managed by a Thread Pool. Also,
in the absence of an *official* Thread Pool implementation, JdbcDatasource
and ActiveMonitor spawn their own threads--when they really need to use the
Thread Pool.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] ThreadManager - a block or a system level service?
Posted by Paul Hammant <Pa...@yahoo.com>.
>
>
>For the moment but the long-term strategy would be to move everything to use
>block directly rather than ThreadContext.getThreadPool(). The main reason is
>because that matches how we use it and it would be easier to manage
>performance characteristerics of pool that way.
>
I'm intrigued. You see multiple implementations of threadpool don't you..
-PH
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] ThreadManager - a block or a system level service?
Posted by Peter Donald <do...@apache.org>.
On Thu, 6 Sep 2001 18:22, Paul Hammant wrote:
> Peter.
>
> OK, ThreadPool become a block like any other, in that there would be XML
> in assembly.xml and config.xml. Fine by me.
kool.
> You think that a lot of "core" existing code is not using
> org.apache.avalon.excalibur.thread.ThreadPool and should be.
Maybe ... not sure. All the stuff I write uses it ;)
> Would we have a default Phoenix/Cornerstone block that implemented
> thread-pool and patched it's calls through to the excalibur version?
eseentially - yep.
> Could/should the excalibur version continue to be used directly by
> blocks or should everything migrate to the block based ThreadPool?
For the moment but the long-term strategy would be to move everything to use
block directly rather than ThreadContext.getThreadPool(). The main reason is
because that matches how we use it and it would be easier to manage
performance characteristerics of pool that way.
> (hoping I have understood correctly).
yup ;)
--
Cheers,
Pete
*-----------------------------------------------------------------------*
PROGRAM: n. a magic spell cast over a computer allowing it to turn
one's input into error messages. v.t. to engage in a pastime similar
to banging one's head against a wall, but with fewer opportunities for
reward.
*-----------------------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [phoenix] ThreadManager - a block or a system level service?
Posted by Paul Hammant <Pa...@yahoo.com>.
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org