-
Notifications
You must be signed in to change notification settings - Fork 5.3k
router: support customizable retry back-off intervals #6568
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -59,9 +59,22 @@ RetryStateImpl::RetryStateImpl(const RetryPolicy& route_policy, Http::HeaderMap& | |
|
|
||
| retry_on_ = route_policy.retryOn(); | ||
| retries_remaining_ = std::max(retries_remaining_, route_policy.numRetries()); | ||
| const uint32_t base = runtime_.snapshot().getInteger("upstream.base_retry_backoff_ms", 25); | ||
| // Cap the max interval to 10 times the base interval to ensure reasonable backoff intervals. | ||
| backoff_strategy_ = std::make_unique<JitteredBackOffStrategy>(base, base * 10, random_); | ||
|
|
||
| std::chrono::milliseconds base_interval( | ||
| runtime_.snapshot().getInteger("upstream.base_retry_backoff_ms", 25)); | ||
| if (route_policy.baseInterval()) { | ||
| base_interval = *route_policy.baseInterval(); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Seems like this means that it's not possible to override the interval with runtime anymore once it specified in the route config. Did you consider keeping the runtime value as an override for retries specified in the config? Not sure which option is better, I can see both sides.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I could imagine adding a config point for a runtime key to use for overriding a route's back-off interval, but it doesn't feel right to me to have the runtime key override the interval for all the routes. Given that there's no runtime key override for the per-try timeout, I think it makes sense to do it this way. I think it could even be argued that I should deprecate the runtime key.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Got it, that makes sense |
||
| } | ||
|
|
||
| // By default, cap the max interval to 10 times the base interval to ensure reasonable back-off | ||
| // intervals. | ||
| std::chrono::milliseconds max_interval = base_interval * 10; | ||
| if (route_policy.maxInterval()) { | ||
| max_interval = *route_policy.maxInterval(); | ||
| } | ||
|
|
||
| backoff_strategy_ = std::make_unique<JitteredBackOffStrategy>(base_interval.count(), | ||
| max_interval.count(), random_); | ||
| host_selection_max_attempts_ = route_policy.hostSelectionMaxAttempts(); | ||
|
|
||
| // Merge in the headers. | ||
|
|
||
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.
Why is the floor function needed? Won't the backoff eventually (or quite quickly) raise this to a useful value?
Uh oh!
There was an error while loading. Please reload this page.
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.
The current implementation takes an integer and assumes it's milliseconds. It also asserts that the value is >= 1. I think I could convert it to handle arbitrary std::chrono::duration types, but I wanted to limit the blast radius of this change.