Package com.couchbase.client.core.retry

Class BestEffortRetryStrategy

java.lang.Object

com.couchbase.client.core.retry.BestEffortRetryStrategy

All Implemented Interfaces:

RetryStrategy

public class BestEffortRetryStrategy
extends Object
implements RetryStrategy

Retries operations on a best-effort basis until they time out.

This is the default retry strategy in the SDK and it works under the assumption that all errors which are retryable in the first place will be retried until the operation times out.

By default, the time paused between the retries is using an exponential backoff strategy, starting at 1 milliseconds and up to 500 milliseconds (see DEFAULT_EXPONENTIAL_BACKOFF). If needed, this backoff can be customized by instantiating a custom instance through the withExponentialBackoff(Duration, Duration, int) method.

While slightly advanced, this class is designed to be extended and the shouldRetry(Request, RetryReason) can be overridden if needed to perform custom retry logic. See the method javadoc for further details.

Field Summary

Fields

Modifier and Type	Field	Description
static BestEffortRetryStrategy	INSTANCE	Returns the default BestEffortRetryStrategy instance.

Constructor Summary

Constructors

Modifier	Constructor	Description
protected	BestEffortRetryStrategy()	Creates a new BestEffortRetryStrategy with the DEFAULT_EXPONENTIAL_BACKOFF.
protected	BestEffortRetryStrategy(Backoff backoff)	Creates a new BestEffortRetryStrategy with aa custom Backoff.

Method Summary

Modifier and Type	Method	Description
CompletableFuture<RetryAction>	shouldRetry(Request<? extends Response> request, RetryReason reason)	Determines if a request should be retried or not (and if so, after which duration).
String	toString()
static BestEffortRetryStrategy	withExponentialBackoff(Duration lower, Duration upper, int factor)	Creates a new BestEffortRetryStrategy with custom exponential backoff boundaries.

Methods inherited from class java.lang.Object

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

Field Detail

INSTANCE

public static final BestEffortRetryStrategy INSTANCE

Returns the default BestEffortRetryStrategy instance.

Constructor Detail

BestEffortRetryStrategy

protected BestEffortRetryStrategy()

Creates a new BestEffortRetryStrategy with the DEFAULT_EXPONENTIAL_BACKOFF.

BestEffortRetryStrategy

protected BestEffortRetryStrategy(Backoff backoff)

Creates a new BestEffortRetryStrategy with aa custom Backoff.

Parameters:

backoff - the custom backoff that should be used.

Method Detail

withExponentialBackoff

public static BestEffortRetryStrategy withExponentialBackoff(Duration lower,
                                                             Duration upper,
                                                             int factor)

Creates a new BestEffortRetryStrategy with custom exponential backoff boundaries.

Parameters:

lower - the lower backoff boundary.

upper - the upper backoff boundary.

factor - the exponential factor to use.

Returns:

the instantiated BestEffortRetryStrategy.

shouldRetry

public CompletableFuture<RetryAction> shouldRetry(Request<? extends Response> request,
                                                  RetryReason reason)

Determines if a request should be retried or not (and if so, after which duration).

In this implementation, the operation will always be retried if it is either idempotent or if the retry reason also allows operations to be retried that are not idempotent. If retry is possible, the next duration based on the configured backoff algorithm is chosen and returned.

This method is designed to be overridden by sub-classes. The common use case is that some retry reasons should not be retried while others should be handled as usual. In this case, override this method but make sure to preform custom checks for specific retry reasons (i.e. RetryReason.ENDPOINT_CIRCUIT_OPEN) but then call this method through super so that all the other reasons are handled properly.

While most of the time a CompletableFuture is constructed immediately, it is possible to call out into external systems through the async mechanism without blocking all the other components in the system. If you do call out over the network or into files, make sure to NEVER block and follow the usual async java/reactor coding best practices.

Specified by:

shouldRetry in interface RetryStrategy

Parameters:

request - the request that is affected.

reason - the reason why the operation should be retried in the first place.

Returns:

a future that when complete indicates the next RetryAction to take.

toString

public String toString()

Overrides:

toString in class Object