avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: Startable doesn't has a isRunning() interface ?
Date Wed, 08 Oct 2003 18:43:58 GMT
Stephen McConnell wrote:
> I think the real underlying issue here is component/container
> responsibility. Who should be creating and supervising/monitoring the
> thread - the component or the container?

option 1: use a seperate executor component [1]. That way, you can opt 
to provide a customized container-managed executor which implements 
container-specific callbacks for thread monitoring. Call this the 
"dynamic responsibility" pattern if you will...maybe I'll write a 
seperate e-mail about that :D

option 2: consider any 'thread management error' a corruption of state 
and propagate that state to all client components (ie throw a functional 
variant of IllegalStateException), which would lead to a whole 
'functional block' of of components being invalidated. Add an 
interceptor/aspect/explicit callback to check for these exceptions and 
act appropriately (usually: dispose of, log problems, then recreate the 
entire 'functional block') [2].

option 3: accept that thread corruption will require human intervention 
(which might be implemented using some kind of logwatch utility and/or 
an exception callback).

option 4: make dealing with thread corruption the responsibility of the 
component itself

I've implemented #2 once (where you aspect everything, monitoring for 
InterruptedException and/or IllegalStateException and/or Error and 
reload a phoenix sar through the JMX interface when you detect any). I'm 
playing around with #1 at the moment. Option 3 actually suffices for 
many applications (thread corruption is rare). Option #4 is I think the 
one currently most common in avalon-based applications.

cheers!

- Leo

[1] - 
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/Executor.html
[2] - http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonNoLogging



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message