Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Date: Thu, 25 Feb 2016 23:18:18 +0000 (UTC)
From: "Xu Zhang (JIRA)" <jira@apache.org>
To: dev@curator.apache.org
Message-ID: <JIRA.12863645.1442088496000.149919.1456442298272@Atlassian.JIRA>
In-Reply-To: <JIRA.12863645.1442088496000@Atlassian.JIRA>
References: <JIRA.12863645.1442088496000@Atlassian.JIRA>
 <JIRA.12863645.1442088496857@arcas>
Subject: [jira] [Commented] (CURATOR-262) Issue with ExponentialBackoffRetry
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CURATOR-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15168091#comment-15168091 ] 

Xu Zhang commented on CURATOR-262:
----------------------------------

Oh I see, I think you r right. 

> 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)