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

Reply via email to