You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several scenarios where the current (default) implementation of BackoffStrategy.calculateExponentialDelay(..) breaks. Specifically:
Silent overflows may happen for 1L << retriesAttempted resulting in incorrect value, often negative, starting with 63 retry attempts (which is a lot, but not unthinkable and actually happened in our logic).
Even if 1L << retriesAttempted part doesn't overflow, it then gets multiplied by baseDelay.toMillis() which, again, may cause an overflow with unpredictable result (small or large in absolute value, negative or positive, practically anything).
baseDelay.toMillis() as well as maxBackoffTime.toMillis() may fail if the duration is too large for converting to milliseconds. There is no guard against that at the retry policy creation time.
Even if the whole operation doesn't overflow as long it then gets converted to int which renders incorrect result (negative or positive, generally anything).
Apart from incorrect backoff delay this will menifest in unhandled exceptions duringDuration.toMillis() conversion for large durations and also during Random.nextInt(..) with non-positive bound later in jitter-enabled implementations.
Hi @OlegZhukov thank you for reporting the issue! Since you have already written the code to fix the issue, would you like to submit a PR?
zoewangg
added
bug
This issue is a bug.
and removed
investigating
This issue is being investigated and/or work is in progress to resolve the issue.
labels
Oct 3, 2019
Uh oh!
There was an error while loading. Please reload this page.
There are several scenarios where the current (default) implementation of
BackoffStrategy.calculateExponentialDelay(..)
breaks. Specifically:1L << retriesAttempted
resulting in incorrect value, often negative, starting with 63 retry attempts (which is a lot, but not unthinkable and actually happened in our logic).1L << retriesAttempted
part doesn't overflow, it then gets multiplied bybaseDelay.toMillis()
which, again, may cause an overflow with unpredictable result (small or large in absolute value, negative or positive, practically anything).baseDelay.toMillis()
as well asmaxBackoffTime.toMillis()
may fail if the duration is too large for converting to milliseconds. There is no guard against that at the retry policy creation time.long
it then gets converted toint
which renders incorrect result (negative or positive, generally anything).Apart from incorrect backoff delay this will menifest in unhandled exceptions during
Duration.toMillis()
conversion for large durations and also duringRandom.nextInt(..)
with non-positive bound later in jitter-enabled implementations.Proposed fix
Unit test:
The text was updated successfully, but these errors were encountered: