You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/sdk_behaviors/retries.rst
+33-14Lines changed: 33 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,6 +11,39 @@ By default, operations exposed in the SDK do not retry, but retries can be set i
11
11
12
12
A sample on using retries, including the default strategy and a custom strategy, can be found on `GitHub <https://github.com/oracle/oci-python-sdk/blob/master/examples/retries.py>`__
13
13
14
+
Exponential Backoff
15
+
-------------------
16
+
The client application must implement retries responsibly. If there are N clients retrying for the same resource the work done by service increases proportionally to N^2 as N clients retry in first round, N-1 in second and so on. This quadratic increase in workload can overwhelm the system and can cause further degradation of a service which might already be under stress. A common strategy to avoid this is to use exponential backoff. This strategy essentially makes the client wait progressively longer after each consecutive retry which is exponential in nature.
17
+
18
+
The wait interval with exponential backoff would be as below:-
Exponential backoff solves the problem of overwhelming the service by spreading the retries over a longer interval of time; however, the N clients still retry in lockstep, albeit with retries spaced exponentially farther apart. To remove this synchronous behavior of the retrying clients we can add jitter, which adds randomness, to the wait interval helping these clients to avoid collision.
25
+
26
+
There are different strategies to implement these timed backoff delays as mentioned below.
27
+
28
+
Full Jitter
29
+
^^^^^^^^^^^^
30
+
Instead of using a constant time we can instead use a random value between 0 and the exponential backoff time.
31
+
32
+
Exponential backoff with full jitter is used for other scenarios where we need to retry because of a failure (e.g. timeouts, HTTP 5xx). The sleep time in this circumstance is calculated as:
In this strategy we keep some amount of the original backoff and jitter on smaller amount. The intuition behind this it to avoid short sleep scenarios which can again lead to overwhelming the service.
40
+
41
+
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:
The default retry strategy vended by the SDK has the following attributes:
@@ -23,20 +56,6 @@ The default retry strategy vended by the SDK has the following attributes:
23
56
* An exponent of 2. When calculating the next retry time we will raise this to the power of the number of attempts
24
57
* A maximum wait time between calls of 30 seconds
25
58
26
-
* 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 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:
0 commit comments