You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Olivier Terrier (JIRA)" <ui...@incubator.apache.org> on 2009/03/31 11:55:50 UTC
[jira] Created: (UIMA-1304) Error handling parameters in CPE with a
Vinci processor
Error handling parameters in CPE with a Vinci processor
-------------------------------------------------------
Key: UIMA-1304
URL: https://issues.apache.org/jira/browse/UIMA-1304
Project: UIMA
Issue Type: Bug
Components: Collection Processing
Affects Versions: 2.2.2
Reporter: Olivier Terrier
Priority: Minor
The handling of the error handling parameters of a CPE that has a Vinci remote Cas processor with its "service-access" deployment parameter set to "random" is buggy
If you set the error parameters to the following values:
<errorHandling>
<errorRateThreshold action="continue" value="10/1000" />
<maxConsecutiveRestarts action="continue" value="10"
waitTimeBetweenRetries="10000" />
<timeout max="600000" default="-1" />
</errorHandling>
It looks like, when the Vinci processor fails for some reason, the CPE intents gracefully to reconnect up to N times (N=10 which is the value of the maxConsecutiveRestarts parameter) which is the expected behaviour. But the "waitTimeBetweenRetries" delay is not used at all.
Apparently in the implementation of method:
private int attachToServices(boolean redeploy, String aServiceUri, int howMany,
ProcessingContainer aProcessingContainer) throws Exception;
of the class org.apache.uima.collection.impl.cpm.container.deployer.vinci.VinciCasProcessorDeployer
the "sleepBetweenRetries" only occurs if the Vinci Cas processor is in "exclusive" mode.
On the contrary (random mode) the method calls directly the method
private synchronized boolean
activateProcessor(CasProcessorConfiguration aCasProcessorConfig,
String aService, ProcessingContainer aProcessingContainer, boolean redeploy);
Which uses a hard coded timeout of 1 sec (SLEEP_TIME) between each retries instead of the waitTimeBetweenRetries.
The bug has been confirmed by Jerry Cwillick and he proposed the attached patch which solves the problem
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1304) Error handling parameters in CPE with a
Vinci processor
Posted by "Olivier Terrier (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Olivier Terrier updated UIMA-1304:
----------------------------------
Attachment: UIMA-1304.clr.patch
> Error handling parameters in CPE with a Vinci processor
> -------------------------------------------------------
>
> Key: UIMA-1304
> URL: https://issues.apache.org/jira/browse/UIMA-1304
> Project: UIMA
> Issue Type: Bug
> Components: Collection Processing
> Affects Versions: 2.2.2
> Reporter: Olivier Terrier
> Priority: Minor
> Attachments: UIMA-1304.clr.patch
>
>
> The handling of the error handling parameters of a CPE that has a Vinci remote Cas processor with its "service-access" deployment parameter set to "random" is buggy
> If you set the error parameters to the following values:
> <errorHandling>
> <errorRateThreshold action="continue" value="10/1000" />
> <maxConsecutiveRestarts action="continue" value="10"
> waitTimeBetweenRetries="10000" />
> <timeout max="600000" default="-1" />
> </errorHandling>
> It looks like, when the Vinci processor fails for some reason, the CPE intents gracefully to reconnect up to N times (N=10 which is the value of the maxConsecutiveRestarts parameter) which is the expected behaviour. But the "waitTimeBetweenRetries" delay is not used at all.
> Apparently in the implementation of method:
> private int attachToServices(boolean redeploy, String aServiceUri, int howMany,
> ProcessingContainer aProcessingContainer) throws Exception;
> of the class org.apache.uima.collection.impl.cpm.container.deployer.vinci.VinciCasProcessorDeployer
> the "sleepBetweenRetries" only occurs if the Vinci Cas processor is in "exclusive" mode.
> On the contrary (random mode) the method calls directly the method
> private synchronized boolean
> activateProcessor(CasProcessorConfiguration aCasProcessorConfig,
> String aService, ProcessingContainer aProcessingContainer, boolean redeploy);
> Which uses a hard coded timeout of 1 sec (SLEEP_TIME) between each retries instead of the waitTimeBetweenRetries.
> The bug has been confirmed by Jerry Cwiklik and he proposed the attached patch which solves the problem
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-1304) Error handling parameters in CPE with a
Vinci processor
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik closed UIMA-1304.
-------------------------------
Resolution: Fixed
Applied the patch
> Error handling parameters in CPE with a Vinci processor
> -------------------------------------------------------
>
> Key: UIMA-1304
> URL: https://issues.apache.org/jira/browse/UIMA-1304
> Project: UIMA
> Issue Type: Bug
> Components: Collection Processing
> Affects Versions: 2.2.2
> Reporter: Olivier Terrier
> Priority: Minor
> Attachments: UIMA-1304.clr.patch
>
>
> The handling of the error handling parameters of a CPE that has a Vinci remote Cas processor with its "service-access" deployment parameter set to "random" is buggy
> If you set the error parameters to the following values:
> <errorHandling>
> <errorRateThreshold action="continue" value="10/1000" />
> <maxConsecutiveRestarts action="continue" value="10"
> waitTimeBetweenRetries="10000" />
> <timeout max="600000" default="-1" />
> </errorHandling>
> It looks like, when the Vinci processor fails for some reason, the CPE intents gracefully to reconnect up to N times (N=10 which is the value of the maxConsecutiveRestarts parameter) which is the expected behaviour. But the "waitTimeBetweenRetries" delay is not used at all.
> Apparently in the implementation of method:
> private int attachToServices(boolean redeploy, String aServiceUri, int howMany,
> ProcessingContainer aProcessingContainer) throws Exception;
> of the class org.apache.uima.collection.impl.cpm.container.deployer.vinci.VinciCasProcessorDeployer
> the "sleepBetweenRetries" only occurs if the Vinci Cas processor is in "exclusive" mode.
> On the contrary (random mode) the method calls directly the method
> private synchronized boolean
> activateProcessor(CasProcessorConfiguration aCasProcessorConfig,
> String aService, ProcessingContainer aProcessingContainer, boolean redeploy);
> Which uses a hard coded timeout of 1 sec (SLEEP_TIME) between each retries instead of the waitTimeBetweenRetries.
> The bug has been confirmed by Jerry Cwiklik and he proposed the attached patch which solves the problem
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1304) Error handling parameters in CPE with a
Vinci processor
Posted by "Olivier Terrier (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Olivier Terrier updated UIMA-1304:
----------------------------------
Description:
The handling of the error handling parameters of a CPE that has a Vinci remote Cas processor with its "service-access" deployment parameter set to "random" is buggy
If you set the error parameters to the following values:
<errorHandling>
<errorRateThreshold action="continue" value="10/1000" />
<maxConsecutiveRestarts action="continue" value="10"
waitTimeBetweenRetries="10000" />
<timeout max="600000" default="-1" />
</errorHandling>
It looks like, when the Vinci processor fails for some reason, the CPE intents gracefully to reconnect up to N times (N=10 which is the value of the maxConsecutiveRestarts parameter) which is the expected behaviour. But the "waitTimeBetweenRetries" delay is not used at all.
Apparently in the implementation of method:
private int attachToServices(boolean redeploy, String aServiceUri, int howMany,
ProcessingContainer aProcessingContainer) throws Exception;
of the class org.apache.uima.collection.impl.cpm.container.deployer.vinci.VinciCasProcessorDeployer
the "sleepBetweenRetries" only occurs if the Vinci Cas processor is in "exclusive" mode.
On the contrary (random mode) the method calls directly the method
private synchronized boolean
activateProcessor(CasProcessorConfiguration aCasProcessorConfig,
String aService, ProcessingContainer aProcessingContainer, boolean redeploy);
Which uses a hard coded timeout of 1 sec (SLEEP_TIME) between each retries instead of the waitTimeBetweenRetries.
The bug has been confirmed by Jerry Cwiklik and he proposed the attached patch which solves the problem
was:
The handling of the error handling parameters of a CPE that has a Vinci remote Cas processor with its "service-access" deployment parameter set to "random" is buggy
If you set the error parameters to the following values:
<errorHandling>
<errorRateThreshold action="continue" value="10/1000" />
<maxConsecutiveRestarts action="continue" value="10"
waitTimeBetweenRetries="10000" />
<timeout max="600000" default="-1" />
</errorHandling>
It looks like, when the Vinci processor fails for some reason, the CPE intents gracefully to reconnect up to N times (N=10 which is the value of the maxConsecutiveRestarts parameter) which is the expected behaviour. But the "waitTimeBetweenRetries" delay is not used at all.
Apparently in the implementation of method:
private int attachToServices(boolean redeploy, String aServiceUri, int howMany,
ProcessingContainer aProcessingContainer) throws Exception;
of the class org.apache.uima.collection.impl.cpm.container.deployer.vinci.VinciCasProcessorDeployer
the "sleepBetweenRetries" only occurs if the Vinci Cas processor is in "exclusive" mode.
On the contrary (random mode) the method calls directly the method
private synchronized boolean
activateProcessor(CasProcessorConfiguration aCasProcessorConfig,
String aService, ProcessingContainer aProcessingContainer, boolean redeploy);
Which uses a hard coded timeout of 1 sec (SLEEP_TIME) between each retries instead of the waitTimeBetweenRetries.
The bug has been confirmed by Jerry Cwillick and he proposed the attached patch which solves the problem
> Error handling parameters in CPE with a Vinci processor
> -------------------------------------------------------
>
> Key: UIMA-1304
> URL: https://issues.apache.org/jira/browse/UIMA-1304
> Project: UIMA
> Issue Type: Bug
> Components: Collection Processing
> Affects Versions: 2.2.2
> Reporter: Olivier Terrier
> Priority: Minor
> Attachments: UIMA-1304.clr.patch
>
>
> The handling of the error handling parameters of a CPE that has a Vinci remote Cas processor with its "service-access" deployment parameter set to "random" is buggy
> If you set the error parameters to the following values:
> <errorHandling>
> <errorRateThreshold action="continue" value="10/1000" />
> <maxConsecutiveRestarts action="continue" value="10"
> waitTimeBetweenRetries="10000" />
> <timeout max="600000" default="-1" />
> </errorHandling>
> It looks like, when the Vinci processor fails for some reason, the CPE intents gracefully to reconnect up to N times (N=10 which is the value of the maxConsecutiveRestarts parameter) which is the expected behaviour. But the "waitTimeBetweenRetries" delay is not used at all.
> Apparently in the implementation of method:
> private int attachToServices(boolean redeploy, String aServiceUri, int howMany,
> ProcessingContainer aProcessingContainer) throws Exception;
> of the class org.apache.uima.collection.impl.cpm.container.deployer.vinci.VinciCasProcessorDeployer
> the "sleepBetweenRetries" only occurs if the Vinci Cas processor is in "exclusive" mode.
> On the contrary (random mode) the method calls directly the method
> private synchronized boolean
> activateProcessor(CasProcessorConfiguration aCasProcessorConfig,
> String aService, ProcessingContainer aProcessingContainer, boolean redeploy);
> Which uses a hard coded timeout of 1 sec (SLEEP_TIME) between each retries instead of the waitTimeBetweenRetries.
> The bug has been confirmed by Jerry Cwiklik and he proposed the attached patch which solves the problem
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-1304) Error handling parameters in CPE with a
Vinci processor
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor updated UIMA-1304:
---------------------------------
Fix Version/s: 2.3
> Error handling parameters in CPE with a Vinci processor
> -------------------------------------------------------
>
> Key: UIMA-1304
> URL: https://issues.apache.org/jira/browse/UIMA-1304
> Project: UIMA
> Issue Type: Bug
> Components: Collection Processing
> Affects Versions: 2.2.2
> Reporter: Olivier Terrier
> Priority: Minor
> Fix For: 2.3
>
> Attachments: UIMA-1304.clr.patch
>
>
> The handling of the error handling parameters of a CPE that has a Vinci remote Cas processor with its "service-access" deployment parameter set to "random" is buggy
> If you set the error parameters to the following values:
> <errorHandling>
> <errorRateThreshold action="continue" value="10/1000" />
> <maxConsecutiveRestarts action="continue" value="10"
> waitTimeBetweenRetries="10000" />
> <timeout max="600000" default="-1" />
> </errorHandling>
> It looks like, when the Vinci processor fails for some reason, the CPE intents gracefully to reconnect up to N times (N=10 which is the value of the maxConsecutiveRestarts parameter) which is the expected behaviour. But the "waitTimeBetweenRetries" delay is not used at all.
> Apparently in the implementation of method:
> private int attachToServices(boolean redeploy, String aServiceUri, int howMany,
> ProcessingContainer aProcessingContainer) throws Exception;
> of the class org.apache.uima.collection.impl.cpm.container.deployer.vinci.VinciCasProcessorDeployer
> the "sleepBetweenRetries" only occurs if the Vinci Cas processor is in "exclusive" mode.
> On the contrary (random mode) the method calls directly the method
> private synchronized boolean
> activateProcessor(CasProcessorConfiguration aCasProcessorConfig,
> String aService, ProcessingContainer aProcessingContainer, boolean redeploy);
> Which uses a hard coded timeout of 1 sec (SLEEP_TIME) between each retries instead of the waitTimeBetweenRetries.
> The bug has been confirmed by Jerry Cwiklik and he proposed the attached patch which solves the problem
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.