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