Holds the parameters for
retry or
poll logic with jitter, timeout and exponential
backoff. Actual implementation of the logic is elsewhere.
The intent of these settings is to be used with a call to a remote server, which could either
fail (and return an error code) or not respond (and cause a timeout). When there is a failure or
timeout, the logic should keep trying until the total timeout has passed.
The "total timeout" parameter has ultimate control over how long the logic should keep trying
the remote call until it gives up completely. The higher the total timeout, the more retries can
be attempted. The other settings are considered more advanced.
Retry delay and timeout start at specific values, and are tracked separately from each other.
The very first call (before any retries) will use the initial timeout.
If the last remote call is a failure, then the retrier will wait for the current retry delay
before attempting another call, and then the retry delay will be multiplied by the retry delay
multiplier for the next failure. The timeout will not be affected, except in the case where the
timeout would result in a deadline past the total timeout; in that circumstance, a new timeout
value is computed which will terminate the call when the total time is up.
If the last remote call is a timeout, then the retrier will compute a new timeout and make
another call. The new timeout is computed by multiplying the current timeout by the timeout
multiplier, but if that results in a deadline after the total timeout, then a new timeout value
is computed which will terminate the call when the total time is up.
Server streaming RPCs interpret RPC timeouts a bit differently. For server streaming RPCs, the
RPC timeout gets converted into a wait timeout
com.google.api.gax.rpc.ApiCallContext#withStreamWaitTimeout(Duration).