Dismiss
Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

# Tolerant Retry Interval Calculation

IP.com Disclosure Number: IPCOM000199807D
Publication Date: 2010-Sep-16
Document File: 5 page(s) / 110K

## Publishing Venue

The IP.com Prior Art Database

## Abstract

Most client-server applications today, use a fixed interval for retrying after a failed attempt. For example, an application could be configured to attempt to talk ‘n’ number of times to a server with a fixed interval of ‘x’ minutes between each attempts. While this would have been sufficient in the past, in today’s multi tier applications, this could worsen a situation by the repeated retry attempts during the failure of any single component. This article makes an attempt to address some of the concerns by providing a more fault tolerant retry interval calculation methods. This way, the clients can wait based on a dynamic self adjusting period to let the servers recover. This article describes two different ways to calculate the interval. It will first introduce an obvious mechanism to calculate the interval and then a better approach that might suit most of the applications.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 5

Tolerant Retry Interval Calculation

Flexible progressive retry interval

This document provides two different ways to calculate the retry interval. While option #1 works for simple client server applications, option #2 seems to be more appropriate in a majority of applications that deals with a fixed maximum session period.

Option #1
An obvious method is to include a delay Factor into the formula, that calculates the interval. This could be achieved as shown below:-

(currentAttemptn* delayFactor) + delta;

Here, n and delayFactor creates a progressive effect on the retry interval. The table below shows the retry interval with the value of 'n' set to 2.

Delay Facto

r

delayFactor=0

delayFactor=2

delayFactor=4

delayFactor=6

(

N=2

)*

Retr

y

=1

30

30

30

30

Retr

y

=2

30

32

34

36

Retr

y

=3

30

38

46

54

Retr

y

=4

30

48

66

84

Retr

y

=5

30

62

94

126

Retr

y

=6

30

80

130

180

[Figure #1 ]

1

Page 2 of 5

In the above chart [Figure #1], when 'delayFactor' is 0, it becomes a non progressive retry model, but as the value of 'delayFactor' increases, the progressive nature of the interval increases. (When delayFactor is set to 2, the first retry happens after 30 units while the second retry happens after 32 units and the one after that occurs after an interval of 38 units. The

progressiveness can be sharpened increasing the delayFactor.)

Cons:

In this case, there is no control over the total period. This is not very useful for applications with a fixed a session period.

Option #

This document introduces a new formula to calculate the progressive interval.

(currentAttempt -1)n * maxPeriod (maxAttempts -1)n

Here, 'n' could any integer which could create a flexible progressive interval. In most cases, a value of 3 will give a good effective interval. maxAttempts is the total number of attempts including the very first attempt.

The chart below is generated with the value of n set to 3 for various session periods. 500, 1000 & 1500 units (seconds/minutes/hours).

max = 500 max=1000 max=1500

Attempt #1 0 0 0

Attempt #2 2 4 6

Attempt #3 18 37 55

Attempt #4 62 125 187

Attempt #5 148 296 444

Attempt #6 289 578 868

Attempt #7 500 1000 1500 [Figure #2]

*

Note that

, unlike Option #1 [Figure#1 ]this chart shows the exact time, the attempts should happen with respect to the start time.

For a session of length 500 units, attempt number #1 happens immediately as noted by '0'. The second attempt occurs at the second minute, the third at the 18th minute and fourth at 62nd minutes and so on..

2

(with Fixed session period

)

2

Page 3 of 5

In the above table, the retries are progressively distributed for the entire session. The session ends within the specified maximum period as seen on the 7th attempt. (which is the value for max attempt).

A fully functional code in Java* which uses the above formula is given below:-

import java.util.Date;

public class ProgressiveRetryRule {

private int maxAttempts;
private long maxSessionInMillis;
private Date firstAttempt;
private Date lastAt...