commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kris Nuttycombe" <Kris.Nuttyco...@noaa.gov>
Subject Re: [pipeline] Error handling question
Date Fri, 03 Dec 2004 00:05:22 GMT
I figure that since pipeline is a brand-new project, there's no harm in 
starting with it being only 1.5-compatible. I guess the risk of doing 
this is that it will probably slow the community growth, but the general 
approach I'm taking is to start with 1.5 and backport to a 
1.4-compatible branch if someone wants it. It's still a small enough 
library and takes advantage of few enough java 1.5 features that a 
backport would only take a couple of hours.

Speaking of building community, I'm going to submit some new xdocs 
through bugzilla here fairly soon, and it would be great if you could 
help me with the process of getting them onto the commons site. If there 
are new xdocs in CVS, do they get pushed up as part of the nightly 
build, or is it a separate process?

Thanks for your help,

Kris


Rory Winston wrote:

> 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?
>
> Cheers,
> Rory
>
> 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: 
>> http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/pipeline/src/java/org/apache/commons/pipeline/impl/SingleThreadStageDriver.java?rev=1.1&view=auto

>>
>>
>> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

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



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


Mime
View raw message