[
https://issues.apache.org/jira/browse/UIMA-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Burn Lewis updated UIMA-1358:
-----------------------------
Attachment: uimaj-as-activemq_1358.patch
Yes, works fine now. This patch adds code to the test driver to test if any
exceptions come back associated with a child CAS. Also named some of the test
threads, and moved some of the "fail" calls so they occur after the service has
been shutdown (otherwise test hangs on failure)
> 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
> Assignee: Burn Lewis
> Fix For: 2.3S
>
> Attachments: uimaj-as-activemq_1358.patch
>
>
> 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.
