Package io.github.flink.gcp.connector.base.retry

Class RetrySchedule

java.lang.Object

io.github.flink.gcp.connector.base.retry.RetrySchedule

@Internal
public final class RetrySchedule
extends Object

An immutable retry schedule: exponential backoff from an initial delay up to a cap, a bounded number of attempts, and optional proportional jitter (to de-synchronize parallel subtasks retrying against the same destination).

Field Summary

Fields

Modifier and Type	Field	Description
static final double	DEFAULT_JITTER_RATIO	The jitter every schedule in this project uses, unless it has a recorded reason not to.

Constructor Summary

Constructors

Constructor	Description
RetrySchedule(long initialBackoffMs, long maxBackoffMs, int maxAttempts, double jitterRatio)	Creates a schedule.

Method Summary

Modifier and Type	Method	Description
long	backoffMs(int attempt)	Returns the jittered backoff after the given attempt (1-based): the initial delay doubled per attempt up to the cap, multiplied by a random factor in [1 - jitterRatio, 1 + jitterRatio].
double	jitterRatio()	Returns the proportional jitter applied to each backoff.
int	maxAttempts()	Returns the maximum number of attempts.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Details

DEFAULT_JITTER_RATIO

public static final double DEFAULT_JITTER_RATIO

The jitter every schedule in this project uses, unless it has a recorded reason not to.

One number rather than a per-site choice, because the value is not load-bearing: the jitter is mean-preserving (the backoff is multiplied by a factor in [1 - ratio, 1 + ratio], so the expected delay stays the design value) and all it has to do is break the synchronization between parallel subtasks retrying against the same destination. Only being non-zero serves that purpose, so a site picking its own ratio would be picking a number nothing distinguishes.

Not a builder knob on any connector's options: there is no workload for which a particular ratio is the right answer, which is the test the recovery* and retry* knobs pass and this does not.

See Also:

• Constant Field Values

Constructor Details

RetrySchedule

public RetrySchedule(long initialBackoffMs,
 long maxBackoffMs,
 int maxAttempts,
 double jitterRatio)

Creates a schedule.

Parameters:

initialBackoffMs - the first backoff

maxBackoffMs - the backoff cap

maxAttempts - the maximum number of attempts

jitterRatio - the proportional jitter, in [0, 1)

Method Details

maxAttempts

public int maxAttempts()

Returns the maximum number of attempts.

jitterRatio

public double jitterRatio()

Returns the proportional jitter applied to each backoff.

backoffMs

public long backoffMs(int attempt)

Returns the jittered backoff after the given attempt (1-based): the initial delay doubled per attempt up to the cap, multiplied by a random factor in [1 - jitterRatio, 1 + jitterRatio].