- All Implemented Interfaces:
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.
INSTANCEpublic static final BestEffortRetryStrategy INSTANCE
backoff- the custom backoff that should be used.
withExponentialBackoffpublic static BestEffortRetryStrategy withExponentialBackoff
(Duration lower, Duration upper, int factor)
lower- the lower backoff boundary.
upper- the upper backoff boundary.
factor- the exponential factor to use.
- the instantiated
shouldRetrypublic 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
CompletableFutureis 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.
toStringpublic String toString()