Exponential Retry Behavior Explained

A common failure situation in service-oriented architectures is temporary unavailable service endpoints. These can easily be handled with retry mechanisms. It’s often useful to increase the wait time between these retries. Oracle SOA Suite supports retry in two different manners: First of all, a retry behavior on Oracle System Faults or custom faults can be defined using the Oracle Fault Handling Framework. Secondly, Oracle SOA Suite supports retry on a technical layer on Java Connector Architecture (JCA) based references, e.g. of database adapters. Both manners provide means to configure growing wait durations. This blog post intends to reveal the underlying mathematical functions.

Exponential Backoff in Oracle Fault Handling Framework
The Oracle Fault Handling Framework provides an out-of-the-box property called exponentialBackoff to enable or disable exponential growth of the wait intervals. By default, exponential backoff is disabled.

In the XML source of the fault-policies.xml, enabled exponential backoff is modelled as empty element exponentialBackoff :

<Action id="default-retry">
  <retry>
    <retryCount>3</retryCount>
    <retryInterval>2</retryInterval>
    <exponentialBackoff/>
    <retryFailureAction ref="default-rethrow"/>
  </retry>
</Action>

On the other hand, disabled exponential backoff doesn’t contains this exponentialBackoff  element:

<Action id="default-retry">
  <retry>
    <retryCount>3</retryCount>
    <retryInterval>2</retryInterval>
    <retryFailureAction ref="default-rethrow"/>
  </retry>
</Action>

But what exactly does exponential growth mean to Oracle? When talking about exponential growth, one usually thinks about the exponential function y = a^x or even the so called normal exponential function y = e^x = exp(x). For the exponential backoff to be defined in Oracle Fault Policy retry actions, exponential means i_n = i₁ * 2^n-1 where i₁ is the initial interval length defined (Retry Interval) and i_n is the interval length for the current retry count n. Example:

(Maximum) Retry Count = n_max = 4, Retry Interval = i₁ = 2, Exponential Backoff = true.

Table 1: Example of exponential growth in Oracle Fault Handling Framework

Retry Count n	Interval Length in [s]	Total retry time [s]
1	i1 = i1 * 21-1 = 2 * 20 = 2 * 1 = 2	2
2	i2 = i1 * 22-1 = 2 * 21 = 2 * 2 = 4	6
3	i3 = i1 * 23-1 = 2 * 22 = 2 * 4 = 8	14
4	i4 = i1 * 24-1 = 2 * 23 = 2 * 8 = 16	30

We can prove this with a simple application trying to write a file to a directory we removed write permissions from.

Exponential Backoff in Oracle JCA Binding Properties
The definition of growing JCA retry is different from this. The underlying function is i_n = i₁ * b^n-1 where i₁ is the initial interval length defined (Retry Interval), i_n is the interval length for the current retry count n and b is the backoff value. (Note: Since 12c, the retry count means the overall tries, that means the initial try plus the additional retries. A retry count defined to 5 results into the initial try plus 4 retries. Details in this blog entry.) Example:

<reference name="WriteFileWithJcaRetry" ui:wsdlLocation="...">
  <interface.wsdl interface="..."/>
  <binding.jca config="Adapters/WriteFileWithJcaRetry_file.jca">
    <property name="jca.retry.count" type="xs:string" many="false">4</property>
    <property name="jca.retry.interval" type="xs:string" many="false">2</property>
    <property name="jca.retry.backoff" type="xs:string" many="false">3</property>
  </binding.jca>
</reference>

(Maximum) Retry Count = n_max = 4, Retry Interval = i₁ = 2, Backoff = b = 3.

Table 2: Example of exponential growth using Oracle JCA Adapter Endpoint Properties

Retry Count n	Interval Length in [s]	Total retry time [s]
1	i1 = i1 * 31-1 = 2 * 30 = 2 * 1 = 2	2
2	i2 = i1 * 32-1 = 2 * 21 = 2 * 3 = 6	8
3	i3 = i1 * 33-1 = 2 * 32 = 2 * 9 = 18	26

Once again the flow trace of the sample application. This time without fault policies but the JCA retry behavior specified above.

To achieve the same exponential growth for a JCA Binding Property based retry as for the Fault Policy based exponential retry, simple select b = 2.

Concluding both retry mechanisms, two key point should be kept in mind: JCA Binding Property based retry behavior provides more flexibility to the retry interval growth. On the other hand, Fault Policy based retry can be configured to any kind of fault while JCA Binding Property based retry cannot. It’s purely for JCA adapter connections as the property name specifies.