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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: