This is a small extension to Google's Guava library to allow for the creation of configurable retrying strategies for an arbitrary function call, such as something that talks to a remote service with flaky uptime.
Apache License 2.0
1.43k
stars
275
forks
source link
WaitStrategies documentation should mention milliseconds #93
Consider WaitStrategies.fibonacciWait(3, TimeUnit.MINUTES) with StopStrategies.stopAfterAttempt(5). I would expect this to run with delays of something like 1 minute, 1 minutes, 2 minutes, 3 minutes. In fact, it runs with 1ms, 1ms, 2ms, and 3ms -- it never gets anywhere near 3 minutes.
The "multiplier" in WaitStrategies.fibonacciWait(long multiplier, long maximumTime, java.util.concurrent.TimeUnit maximumTimeUnit) is actually what these millisecond numbers get multiplied by.
The docs never mention milliseconds anywhere, so I am very confused to see them used.
On reflection, it makes sense that wait strategies are unrelated to stop strategies, and thus in general, wait strategies can't take into account how many tries are needed. So they need some sort of default.
But I do think that a doc change would help with this. I also think that "implicit milliseconds" is an error-prone API, especially when there is already a TimeUnit given. So I would love to see a new version of the API that computes incremental wait times based on the maximum wait time. Or some other API change to avoid the "implicit milliseconds" problem.
Consider
WaitStrategies.fibonacciWait(3, TimeUnit.MINUTES)withStopStrategies.stopAfterAttempt(5). I would expect this to run with delays of something like 1 minute, 1 minutes, 2 minutes, 3 minutes. In fact, it runs with 1ms, 1ms, 2ms, and 3ms -- it never gets anywhere near 3 minutes.The "multiplier" in
WaitStrategies.fibonacciWait(long multiplier, long maximumTime, java.util.concurrent.TimeUnit maximumTimeUnit)is actually what these millisecond numbers get multiplied by.The docs never mention milliseconds anywhere, so I am very confused to see them used.
On reflection, it makes sense that wait strategies are unrelated to stop strategies, and thus in general, wait strategies can't take into account how many tries are needed. So they need some sort of default.
But I do think that a doc change would help with this. I also think that "implicit milliseconds" is an error-prone API, especially when there is already a TimeUnit given. So I would love to see a new version of the API that computes incremental wait times based on the maximum wait time. Or some other API change to avoid the "implicit milliseconds" problem.