Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Date: Sat, 12 Sep 2015 20:08:46 +0000 (UTC)
From: "Dimitar Dyankov (JIRA)" <jira@apache.org>
To: dev@curator.apache.org
Message-ID: <JIRA.12863645.1442088496000.323028.1442088526134@Atlassian.JIRA>
In-Reply-To: <JIRA.12863645.1442088496000@Atlassian.JIRA>
References: <JIRA.12863645.1442088496000@Atlassian.JIRA>
 <JIRA.12863645.1442088496857@arcas>
Subject: [jira] [Created] (CURATOR-262) Issue with ExponentialBackoffRetry
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Dimitar Dyankov created CURATOR-262:
---------------------------------------

             Summary: Issue with ExponentialBackoffRetry
                 Key: CURATOR-262
                 URL: https://issues.apache.org/jira/browse/CURATOR-262
             Project: Apache Curator
          Issue Type: Bug
            Reporter: Dimitar Dyankov
            Assignee: Jordan Zimmerman


Hi,

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

    @Override
    protected int getSleepTimeMs(int retryCount, long elapsedTimeMs)
    {
        // copied from Hadoop's RetryPolicies.java
        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, maxSleepMs));
            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
(v6.3.4#6332)