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)