Replies: 1 comment
-
I think it would be rather trivial to implement all of the jitters (but now strings; nature gave us enums for that ;)) – but what problem are you exactly trying to solve? IIRC all approaches were roughly equivalent? IOW is this actually a problem or more an urge of completionism? :) To be clear, I’m not asking to be a jerk, but because if we add this, we need to explain why in the docs – ideally with concrete examples. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
First off, thanks for creating and maintaining stamina!
Re my request, it would be great if stamina could support the "Full Jitter" algorithm described in the Exponentional Backoff and Jitter article on the AWS architecture blog.
Currently stamina calculates the retry
wait_time
as:Which adds a fixed jitter in the range
[0, wait_jitter]
on top of the exponential backoff.This works well most of the time, but it doesn't allow the "retry window" to grow as the number of retry attempts increases (which can be useful in situations like those described in the AWS article).
Under "Full Jitter" the retry wait time is calculated as:
Which causes the retry window to grow exponentially with each attempt.
For reference,
tenacity.wait.wait_random_exponential
uses the "Full Jitter" algorithm.Proposal
Introduce a flag (e.g.
wait_strategy='full_jitter'
) that switches thewait_time
calculation to:This would make it easy to opt into "Full Jitter" behaviour while retaining the current logic as default.
Thanks again for creating the package and no worries if this isn't a feature you want to add to this library.
Beta Was this translation helpful? Give feedback.
All reactions