[jira] Commented: (UIMA-1358) Exceptions on generated CASes are returned to client without parentage information

["Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>]

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

Jerry Cwiklik commented on UIMA-1358:
-------------------------------------

Fixed the code to handle child CAS exceptions. If the child CAS is not allowed to continue after exception, the aggregate marks an input CAS from which the child was produced as failed. All CASes produced from this input CAS will not be allowed to continue and instead will be intercepted and dropped. CAS multipliers still producing from the input CAS will be notified and will stop generation of new CASes. After all children are accounted for, the aggregate returns the input CAS to the client with an exception. The exception identifies the child CAS that caused the error as well as the delegate where the error occurred. 

> 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.