curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dimitar Dyankov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-262) Issue with ExponentialBackoffRetry
Date Fri, 26 Feb 2016 00:26:18 GMT

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

Dimitar Dyankov commented on CURATOR-262:
-----------------------------------------

Done. Here's the link to the pull request https://github.com/apache/curator/pull/136.

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

Mime
View raw message