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