[jira] [Commented] (CURATOR-262) Issue with ExponentialBackoffRetry

["Xu Zhang (JIRA)" <ji...@apache.org>]

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

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

There is a `MAX_RETRIES_LIMIT` in the same file. It cannot be larger than 29.

I think no need to modify this.

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