commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rory Winston <>
Subject Re: [pipeline] Error handling question
Date Thu, 02 Dec 2004 22:48:12 GMT
Hi Kris,

I just did a sample build and test with Maven - it works fine. My only 
question is - are you planning to make [pipeline] 1.5-compatible only 
from this point on, or do you also plan to make it 1.4-compatible as well?


Kris Nuttycombe wrote:

> I'm toying with making the sibling shutdown policy dependent upon the 
> StageDriver implementation, since that's where the policy is actually 
> implemented, and using a configuration parameter probably doesn't 
> provide a sufficient number of error handling policies for all the 
> possible use cases. Since each stage is associated with a StageDriver 
> and the class of the associated StageDriver is specified in the 
> configuration file, it makes it easy to set things up on a 
> stage-by-stage basis. The only problem with this idea is that it 
> doesn't separate error policy implementation from threading policy 
> implementation, so you're likely to get code duplication in (# of 
> threading policies * # of error policies) classes.
> As an aside, the commons-sandbox CVS has been updated with the most 
> current version of the pipeline code, so if you want to see the error 
> handling policy I'm talking about take a look at the WorkerThread 
> inner class here: 

> Kris
> Ken Tanaka wrote:
>> The most flexible scheme seems to have the parent take a 
>> configuration parameter that sets a default policy on interrupting 
>> the children when one child quits on Error. Then the child Stages 
>> could have an optional policy parameter to request different 
>> treatment than the parent's default shutdown policy.
>> -Ken
>> Kris Nuttycombe wrote:
>>> Hi, all,
>>> I've got a exception handling policy question for all of you. Here's 
>>> the situation:
>>> In commons-pipeline, one or more child threads may be spawned to 
>>> control processing for a given stage. What should the error handling 
>>> policy be for Errors generated by the foreign method calls? I catch 
>>> all Exceptions, including RuntimeExceptions, and record the faults 
>>> in a monitor object that is visible at the pipeline level. What I 
>>> don't know is whether or not I should try to catch Errors as well. 
>>> The information in the Error object is obviously potentially useful 
>>> for debugging, but it's almost certain that any Errors that occur 
>>> can't be recovered from and ought to abort processing of the whole 
>>> pipeline.
>>> What should be the default behavior of a parent thread is when a 
>>> child thread dies due to an uncaught Error? Should the policy be to 
>>> immediately interrupt any sibling threads, or does this seem like it 
>>> would make it too easy to leave an external resource modified by a 
>>> Stage in an inconsistent state, and therefore sibling threads should 
>>> be asked to exit gracefully? Maybe the behavior on interruption 
>>> should be something that's set on a stage-by-stage basis?
>>> Thoughts, comments, suggestions?
>>> Kris

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message