Leo Simons wrote:
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
Please do. I'm asking myself to what extent this executor component can be created by the container as opposed to pushifg the overhead onto the component developer. I'm also thinking about the relationship of things like and extended Runnable iterface through which a container can monitor the state of a component.
Stephen.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
