commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kris Nuttycombe" <>
Subject Re: [pipeline] Error handling question
Date Thu, 02 Dec 2004 19:30:00 GMT
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:


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

Kris Nuttycombe
Associate Scientist
Geospatial Data Services Group
CIRES, National Geophysical Data Center/NOAA
(303) 497-6337

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

View raw message