Adam Lally wrote:
On 2/26/07, Adam Lally <[EMAIL PROTECTED]> wrote:
3) Notification of errors to allow continuing after a failure. This
would support an action like the current CPM's "continue" action.
There would be a new API:
Flow.onFailure(String failedAnalysisEngineKey, Throwable failure)
If the runtime wanted to continue after a failure, it would call this
method on the Flow Controller, and then would go back to calling
hasNext/next. Without this notification, a "continue" action wouldn't
make much sense, because a dynamic FlowControlle may make an
assumption that the last step it issued completed successfully.
Note for #2 and #3 I'm not intending on having the existing framework
call these methods, yet. These Flow Controller extensions are a
prerequisite for doing more advanced flow things like parallel flows
and error recovery.
Actually as I think about it more I wonder if it would be better if
when I add the Flow.onFailure() I also change the framework to call
this method when an error occurs. The existing FixedFlowControllers
(such as fixed flow) could just refuse to continue, so the default
beahvior would be unchanged. This could be a configuration parameter
on the FixedFlowController so people could configure their AEs to
continue after errors. It seems like this would provide some value so
may be worth doing, rather than just adding a method that's never
called.
Possibly we might want to allow the application to control whether the
FlowController is consulted when an error occurs. This could be made
configurable through the additionalParams map when the Aggregate AE is
constructed. Then an application could always use "terminate on
error" mode if desired, regardless of the FlowController being used.
Sound also be more reasonable for me... but some additional
comments/questions form my side.
How does it work with the additionalParams map to configure my
application to 'continue'
or 'terminate' in case of errors. Will it be configurable for each
analysis engine separately?
I think it would be very useful since the error handling depends on the
analysis engine. So when using the additionalParams map, does the
application
have to take care how to get the configuration or will that be part of
any of the common descriptors?
I think a good place to specify this will the flowConstraints section in
an aggregate descriptor.
When having a build-in flow, it can look like:
<flowConstraints>
<fixedFlow>
<node errorAction="continue" >ae1</node>
<node errorAction="terminate">ae2</node>
</fixedFlow>
</flowConstraints>
but when having a FlowController plugged in, this section is missing.
But I wonder why. I think for these flows, the order of the
analysis engines can also be relevant. How does this work currently? I
think the order of the analysis engine definition is used, right?
Why we don't have a section like:
<flowConstraints>
<customFlow> <!-- indicates using the imported FlowController -->
<node errorAction="continue" >ae1</node>
<node errorAction="terminate">ae2</node>
</customFlow>
</flowConstraints>
to specify the customFlow items in a oder of choice. So it will be easy
possible to add additional information for each analysis engine to the
FlowController.
-- Michael
