uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Burn Lewis (JIRA)" <uima-...@incubator.apache.org>
Subject [jira] Commented: (UIMA-1358) Exceptions on generated CASes are returned to client without parentage information
Date Tue, 02 Jun 2009 22:05:07 GMT

    [ https://issues.apache.org/jira/browse/UIMA-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715715#action_12715715
] 

Burn Lewis commented on UIMA-1358:
----------------------------------

After more discussions I think the conclusion is ...

The real issue here is what should happen when a delegate in an aggregate reports an error
on a generated CAS and the error handling is configured to not let the CAS continue.  Since
this is the simplest (default) way to handle errors we should take the simplest approach of
reporting the error against the parent CAS, i.e.
* stop generating any more CASes from this parent
* don't start any further processing of CASes already generated by this parent that are still
within the aggregate 
** i.e. don't let them continue in the flow
** if they themselves are in a local or remote Cas Multiplier don't let then generate any
more children
* don't return any more child CASes if this is a Cas Multiplier
* when all children of this parent are accounted for return the exception as if the parent
failed

If additional exceptions occur on other children of the parent they could possibly be added
to the EntityProcessStatus returned to the client.

Note:  Currently the exception is always returned against each failing child, the processing
does not stop, and the parent is returned with no exceptions.

> Exceptions on generated CASes are returned to client without parentage information
> ----------------------------------------------------------------------------------
>
>                 Key: UIMA-1358
>                 URL: https://issues.apache.org/jira/browse/UIMA-1358
>             Project: UIMA
>          Issue Type: Bug
>          Components: Async Scaleout
>    Affects Versions: 2.2.2
>            Reporter: Burn Lewis
>             Fix For: 2.3S
>
>
> The client should be told which of its input CASes might have (indirectly) generated
this failing CAS.  Also is there any value in sending more than one exception if many children
fail?  If the aggregate is not a CM then the client should just be told that the input CAS
failed.
> Here is part of a recent email discussion on this problem:
> I think I have a somewhat clearer picture of how we might handle errors on child CASes.
 
> First consider Primitive & Aggregate CMs, and then a non-CM aggregate that contains
a CM. 
> I can see 3 different ways an application may wish to handle errors on child CASes:
> Primitive CM 
> Stop generating children/descendants of the input CAS and return an exception on the
input CAS
> Generate an "incomplete" CAS -- perhaps marked as "damaged"
> (useful when the total count must be preserved and a place-holder provided)
> Ignore the error, generate no CAS and carry on to generate the next CAS (if any)
> Aggregate CM
> Stop generating any more children/descendants from the input CAS and return the exception
on the input CAS
> Allow the CAS to continue in the flow
> Quietly drop the CAS, do not return it and do not generate an exception
> Simple Aggregate with internal CM
> Stop generating any more children/descendants from the input CAS and return the exception
on the input CAS
> Allow the CAS to continue in the flow (it will be dropped at the end of the flow)
> Quietly drop the CAS as if it reached the end of the flow, and do not generate an exception
> Currently our aggregate error-handling supports #2, while #3 doesn't depend on the framework.
 I have added aggregate support for #3 to the AdvancedFixedFlowController in the UIMA-AS test
suite (as part of Jira 1353) in the form of a new AllowDropOnFailure option which specifies
the delegates for which a failing CAS can be dropped, i.e. skip to the end of the flow with
the forceCasToBeDropped flag set.  (I used it to test the thresholdWindow error handling to
verify that an intermittently failing delegate is disabled when N of the last M CASes fail.)
> But I don't think our docs indicate what should happen in #1 and the current implementation
handles it differently ... the exception is associated with the child CAS without any reference
to the input CAS, and the CM continues to generate children, so the client can get many exceptions
that refer to unknown CASes.  The getParentCasReferenceId() method in the UimaASProcessStatus
(which I could not find in the JavaDocs) can be used to associate a child CAS with the input
CAS that generated it, but it is always null when an exception is returned. 
> Consider the information available to the entityProcessComplete callback when an input
CAS successfully generates 2 children:
> returnedCAS		getCasReferenceId()	getParentCasReferenceId()	isException()
>  
>   Child1 		ID-of-Child1			ID-of-Parent		false
>   Child2 		ID-of-Child2			ID-of-Parent		false
>   Parent 		ID-of-Parent			null				false
> 	If the 2nd child causes an exception then the client might see (Option A)
> returnedCAS		getCasReferenceId()	getParentCasReferenceId()	isException()
>  
>   Child1 		ID-of-Child1			ID-of-Parent		false
>   null 		ID-of-Parent			null				true
> Or we could put the failing child's ID in the status (Option B)
> returnedCAS		getCasReferenceId()	getParentCasReferenceId()	isException()
>  
>   Child1 		ID-of-Child1			ID-of-Parent		false
>   null 		ID-of-Child2			ID-of-Parent		true
> Note that in an Aggregate CM the failing CAS may not have been generated directly by
the parent, but by any one of its descendants.
> I think option A  is cleaner and easier to document ... "exception always on input CAS".
 If the ID of the failing child is useful we could wrap the exception in another that said
something like "Exception inherited from generated CAS xyz"
> Any other options we should consider?
> I'll put this in a Jira as that may be the better place to discuss it.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message