You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "Dimitar Dyankov (JIRA)" <ji...@apache.org> on 2016/02/26 00:55:18 UTC

[jira] [Comment Edited] (CURATOR-262) Issue with ExponentialBackoffRetry

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

Dimitar Dyankov edited comment on CURATOR-262 at 2/25/16 11:54 PM:
-------------------------------------------------------------------

I can submit the pull request. Can you please give me some instructions (repo, branch)? This will be my first time doing it for Curator.


was (Author: ddyankov):
I can submit the pull request.

> 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
>              Labels: newbie
>
> 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)