Retries¶
By default, operations exposed in the SDK do not retry, but retries can be set in the SDK on a per-operation basis. Each operation accepts a
retry_strategy
keyword argument which can be used to set the retry strategy for that operation. This retry stategy could be:
- The default strategy vended by the SDK as
DEFAULT_RETRY_STRATEGY
- The
NoneRetryStrategy
. This will result in no retries being performed for the operation - A custom strategy produced via the
RetryStrategyBuilder
A sample on using retries, including the default strategy and a custom strategy, can be found on GitHub
Default Retry Strategy¶
The default retry strategy vended by the SDK has the following attributes:
5 total attempts
Total allowed elapsed time for all requests of 300 seconds (5 minutes)
Exponential backoff with jitter, using:
- The base time to use in retry calculations will be 1 second
- An exponent of 2. When calculating the next retry time we will raise this to the power of the number of attempts
- A maximum wait time between calls of 30 seconds
Exponential backoff with equal jitter is used for throttles as this guarantees some sleep time between attempts. The sleep time in this circumstance is calculated as:
exponential_backoff_sleep_base = min(base_time * (exponent ** attempt_number), max_wait_time)
sleep_time = (exponential_backoff_sleep_base / 2.0) + random(0, exponential_backoff_sleep_base / 2.0)
- Exponential backoff with full jitter is used for other scenarios where we need to retry (e.g. timeouts, HTTP 5xx). The sleep time in this circumstance is calculated as:
exponential_backoff_sleep_base = min(base_time * (exponent ** attempt_number), max_wait_time)
sleep_time = random(0, exponential_backoff_sleep_base)
Retries on the following exception types:
- Timeouts and connection errors
- HTTP 429s (throttles)
- HTTP 5xx (server errors)