curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dimitar Dyankov (JIRA)" <>
Subject [jira] [Created] (CURATOR-262) Issue with ExponentialBackoffRetry
Date Sat, 12 Sep 2015 20:08:46 GMT
Dimitar Dyankov created CURATOR-262:

             Summary: Issue with ExponentialBackoffRetry
                 Key: CURATOR-262
             Project: Apache Curator
          Issue Type: Bug
            Reporter: Dimitar Dyankov
            Assignee: Jordan Zimmerman


Looking at the ExponentialBackOff Strategy for the apache curator I found this issue :

    protected int getSleepTimeMs(int retryCount, long elapsedTimeMs)
        // copied from Hadoop's
        int sleepMs = baseSleepTimeMs * Math.max(1, random.nextInt(1 << (retryCount
+ 1)));
        if ( sleepMs > maxSleepMs )
            log.warn(String.format("Sleep extension too large (%d). Pinning to %d", sleepMs,
            sleepMs = maxSleepMs;
        return sleepMs;

since sleepMs is an Integer and retryCount could be as large as 29 we could fall into an integer
overflow case and therefore sleepMs being a negative number.

This message was sent by Atlassian JIRA

View raw message