Skip to content
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.

Sign up for GitHub

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

A6 update: change specification of backoff behavior to make sense #452

Merged
merged 3 commits into from
Aug 29, 2024
+10 −7
Merged

A6 update: change specification of backoff behavior to make sense #452

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
fa84a91
A6 update: change specification of backoff behavior to make sense
markdroth Aug 23, 2024
4cae7e9
apply jitter to initial backoff too
markdroth Aug 28, 2024
f0b9b89
add note about jitter exceeding the configured bounds
markdroth Aug 28, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 10 additions & 7 deletions A6-client-retries.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ gRPC Retry Design
* Approver: a11r
* Status: Implemented
* Implemented in: Java, .NET, Node, Go except hedging, and C-Core except hedging
* Last updated: 2022-11-17
* Last updated: 2024-08-23
* Discussion at: https://groups.google.com/forum/#!topic/grpc-io/zzHIICbwTZE

Table of Contents
Expand Down Expand Up @@ -106,9 +106,11 @@ gRPC's call deadline applies across all attempts for a given RPC. For example, i

##### Exponential Backoff

The `initialBackoff`, `maxBackoff`, and `backoffMultiplier` parameters determine the randomized delay before retry attempts.
The `initialBackoff`, `maxBackoff`, and `backoffMultiplier` parameters tune the exponential delay before retry attempts.

The initial retry attempt will occur at `random(0, initialBackoff)`. In general, the `n`-th attempt will occur at `random(0, min(initialBackoff*backoffMultiplier**(n-1), maxBackoff))`.
Jitter of plus or minus 0.2 is applied to the backoff delay to avoid hammering servers at the same time from a large number of clients. Note that this means that the backoff delay may actually be slightly lower than `initialBackoff` or slightly higher than `maxBackoff`.

The initial retry attempt will occur after `initialBackoff * random(0.8, 1.2)`. After that, the `n`-th attempt will occur after `min(initialBackoff*backoffMultiplier**(n-1), maxBackoff) * random(0.8, 1.2))`.
markdroth marked this conversation as resolved.
Show resolved Hide resolved

##### Retryable Status Codes

Expand Down Expand Up @@ -430,10 +432,11 @@ The retry policy is transmitted to the client through the service config mechani
// This field is required and must be two or greater.
"maxAttempts": number,

// Exponential backoff parameters. The initial retry attempt will occur at
// random(0, initialBackoff). In general, the nth attempt since the last
// server pushback response (if any), will occur at random(0,
// min(initialBackoff*backoffMultiplier**(n-1), maxBackoff)).
// Exponential backoff parameters. The initial retry attempt will occur
// after initialBackoff * random(0.8, 1.2). After that, the nth attempt
// since the last server pushback response (if any), will occur at
// min(initialBackoff*backoffMultiplier**(n-1), maxBackoff) *
// random(0.8, 1.2).
// The following two fields take their form from:
// https://developers.google.com/protocol-buffers/docs/proto3#json
// They are representations of the proto3 Duration type. Note that the
Expand Down