-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PF-4325 Introduce retry backoff weight #66
Conversation
README.md
Outdated
@@ -54,7 +54,8 @@ A subscription queue should be defined to receive any events raised for the subs | |||
**Attributes** | |||
|
|||
- **allow_retry** [Bool] [Optional] [Default=false] This determines if the queue should allow processing failures to be retried. | |||
- **allow_retry_backoff** [Bool] [Optional] [Default=false] This is used to specify if failed messages that retry should incrementally backoff. | |||
- **allow_retry_back_off** [Bool] [Optional] [Default=false] This is used to specify if failed messages that retry should incrementally backoff. | |||
- **back_off_weight** [Int] [Optional] [Default=1] Additional multiplier for the timeout backoff. Normally used when `retry_delay` is too small (eg: 30ms) in order to get meaningful backoff values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make this retry_back_off_weight
to keep the naming convention used for retry_back_off_grace
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, just a sec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 done
…e_retry_backoff_weight
…age/eventq into PF-4325_introduce_retry_backoff_weight
This PR introduces the retry_back_off_weight setting for the Queue class.
This setting functions like an extra multiplier to allow us to have meaningful timeout values when the
retry_delay
is too small.It also adds a utility script that allows us to instrument the
CalculateVisibilityTimeout
class and observe its behaviour using various settings. This allows us to confidently choose the configurations we need.The script lives in
utilities/plot_visibility_timeout.rb
Eg:
Given a grace period of
20_000s
(15min) and a retry delay of30ms
and running a simulation of259309s
(72h).With
queue_back_off_weight = 1
(*Here the calculation is actualy zero but we assume
30ms
by default.So we see the timeout grows very slowly over time resulting in many iterations and after 72h we only have a max timeout of 125s.
With
queue_back_off_weight = 100
From 0 - 20_000 retries we get a timeout of 0.03
With
queue_back_off_weight = 200
With
queue_back_off_weight = 300