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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
