uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Olivier Terrier (JIRA)" <uima-...@incubator.apache.org>
Subject [jira] Created: (UIMA-1304) Error handling parameters in CPE with a Vinci processor
Date Tue, 31 Mar 2009 09:55:50 GMT
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:

          <errorRateThreshold action="continue" value="10/1000" />
          <maxConsecutiveRestarts action="continue" value="10"
waitTimeBetweenRetries="10000" />
          <timeout max="600000" default="-1" />

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.

View raw message