You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Burn Lewis (JIRA)" <ui...@incubator.apache.org> on 2009/05/26 20:52:45 UTC
[jira] Created: (UIMA-1355) When one delagate in a parallel step
fails, the flow continues without waiting for the last reply
When one delagate in a parallel step fails, the flow continues without waiting for the last reply
-------------------------------------------------------------------------------------------------
Key: UIMA-1355
URL: https://issues.apache.org/jira/browse/UIMA-1355
Project: UIMA
Issue Type: Bug
Components: Async Scaleout
Reporter: Burn Lewis
Fix For: 2.3S
When a delegate in a parallel step fails the number of replies received is incremented twice, so the reply from the last delegate is not merged into the CAS. When it is received it will reenter the flow if the CAS is still active, causing even more trouble.
I have a test case that demonstrates the problem.
Also we should make the check for all-replies-received atomic so that only one reply- or error-processing thread will send the CAS on to the next step, or, depending on the error-handling, discard the CAS or terminate the service.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1355) When one delagate in a parallel step
fails, the flow continues without waiting for the last reply
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik updated UIMA-1355:
--------------------------------
Fix Version/s: (was: 2.3S)
2.3AS
> When one delagate in a parallel step fails, the flow continues without waiting for the last reply
> -------------------------------------------------------------------------------------------------
>
> Key: UIMA-1355
> URL: https://issues.apache.org/jira/browse/UIMA-1355
> Project: UIMA
> Issue Type: Bug
> Components: Async Scaleout
> Reporter: Burn Lewis
> Fix For: 2.3AS
>
> Attachments: UIMA-1355_test_uimaj-as-activemq.patch
>
>
> When a delegate in a parallel step fails the number of replies received is incremented twice, so the reply from the last delegate is not merged into the CAS. When it is received it will reenter the flow if the CAS is still active, causing even more trouble.
> I have a test case that demonstrates the problem.
> Also we should make the check for all-replies-received atomic so that only one reply- or error-processing thread will send the CAS on to the next step, or, depending on the error-handling, discard the CAS or terminate the service.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1355) When one delagate in a parallel step
fails, the flow continues without waiting for the last reply
Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Burn Lewis updated UIMA-1355:
-----------------------------
Attachment: UIMA-1355_test_uimaj-as-activemq.patch
Here's a patch that makes testProcessParallelFlowWithDelegateDisable fail as it now checks that the other delegate's results do get merged into the CAS. If the final CheckTextAnnotator does not find a SourceDocumentInformatiom annotation it fails the test.
> When one delagate in a parallel step fails, the flow continues without waiting for the last reply
> -------------------------------------------------------------------------------------------------
>
> Key: UIMA-1355
> URL: https://issues.apache.org/jira/browse/UIMA-1355
> Project: UIMA
> Issue Type: Bug
> Components: Async Scaleout
> Reporter: Burn Lewis
> Fix For: 2.3S
>
> Attachments: UIMA-1355_test_uimaj-as-activemq.patch
>
>
> When a delegate in a parallel step fails the number of replies received is incremented twice, so the reply from the last delegate is not merged into the CAS. When it is received it will reenter the flow if the CAS is still active, causing even more trouble.
> I have a test case that demonstrates the problem.
> Also we should make the check for all-replies-received atomic so that only one reply- or error-processing thread will send the CAS on to the next step, or, depending on the error-handling, discard the CAS or terminate the service.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1355) When one delagate in a parallel step
fails, the flow continues without waiting for the last reply
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik closed UIMA-1355.
-------------------------------
Resolution: Fixed
Modified to prevent double increment of the count that keeps track of how many delegates responded in a parallel step.
> When one delagate in a parallel step fails, the flow continues without waiting for the last reply
> -------------------------------------------------------------------------------------------------
>
> Key: UIMA-1355
> URL: https://issues.apache.org/jira/browse/UIMA-1355
> Project: UIMA
> Issue Type: Bug
> Components: Async Scaleout
> Reporter: Burn Lewis
> Fix For: 2.3S
>
> Attachments: UIMA-1355_test_uimaj-as-activemq.patch
>
>
> When a delegate in a parallel step fails the number of replies received is incremented twice, so the reply from the last delegate is not merged into the CAS. When it is received it will reenter the flow if the CAS is still active, causing even more trouble.
> I have a test case that demonstrates the problem.
> Also we should make the check for all-replies-received atomic so that only one reply- or error-processing thread will send the CAS on to the next step, or, depending on the error-handling, discard the CAS or terminate the service.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.