Class BestEffortRetryStrategy

  • All Implemented Interfaces:

    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.

    • Method Detail

      • 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
        request - the request that is affected.
        reason - the reason why the operation should be retried in the first place.
        a future that when complete indicates the next RetryAction to take.