A basic implementation ofResultRetryAlgorithm. Using this implementation would mean that all exceptions should be retried, all responses should be accepted (includingnull) and no retrying process should ever be canceled.

The retry executor which executes attempts in the current thread, potentially causing the current thread to sleep for the specified amount of time before execution.

This class is thread-safe.

The timed poll algorithm which uses jittered exponential backoff factor for calculating the next poll execution time and throwsPollException in case if total timeout or total number of attempts is reached.

This class is thread-safe.

The timed retry algorithm which uses jittered exponential backoff factor for calculating the next attempt execution time.

This class is thread-safe.

A future which cannot be cancelled from the external package.

For internal use, public for technical reasons.

The retry algorithm, which makes decision based either on the thrown exception or the returned response, and the execution time settings of the previous attempt.

This class is thread-safe.

Holds the parameters forretry orpoll logic with jitter, timeout and exponential backoff. Actual implementation of the logic is elsewhere.

The intent of these settings is to be used with a call to a remote server, which could either fail (and return an error code) or not respond (and cause a timeout). When there is a failure or timeout, the logic should keep trying until the total timeout has passed.

The "total timeout" and "max attempts" settings have ultimate control over how long the logic should keep trying the remote call until it gives up completely. The remote call will be retried until one of those thresholds is crossed. To avoid unbounded rpc calls, it is required to configure one of those settings. If both are 0, then retries will be disabled. The other settings are considered more advanced.

Retry delay and timeout start at specific values, and are tracked separately from each other. The very first call (before any retries) will use the initial timeout.

If the last remote call is a failure, then the retrier will wait for the current retry delay before attempting another call, and then the retry delay will be multiplied by the retry delay multiplier for the next failure. The timeout will not be affected, except in the case where the timeout would result in a deadline past the total timeout; in that circumstance, a new timeout value is computed which will terminate the call when the total time is up.

If the last remote call is a timeout, then the retrier will compute a new timeout and make another call. The new timeout is computed by multiplying the current timeout by the timeout multiplier, but if that results in a deadline after the total timeout, then a new timeout value is computed which will terminate the call when the total time is up.

Server streaming RPCs interpret RPC timeouts a bit differently. For server streaming RPCs, the RPC timeout gets converted into a wait timeoutcom.google.api.gax.rpc.ApiCallContext#withStreamWaitTimeout(Duration).

A base builder class forRetrySettings. See the class documentation ofRetrySettings for a description of the different values that can be set.

The retry executor which usesScheduledExecutorService to schedule an attempt tasks.

This implementation does not manage the lifecycle of the underlyingScheduledExecutorService, so it should be managed outside of this class (like calling theScheduledExecutorService#shutdown() when the pool is not needed anymore). In a typical usage pattern there are usually multiple instances of this class sharing same instance of the underlyingScheduledExecutorService.

This class is thread-safe.

Simplest implementation of aStreamResumptionStrategy which returns the initial request for unstarted streams.

The streaming retry algorithm, which makes decision based either on the thrown exception and the execution time settings of the previous attempt. This extendsRetryAlgorithm to take additional information (provided byServerStreamingAttemptCallable) into account.

This class is thread-safe.

Internal use only - public for technical reasons.

Timed attempt execution settings. Defines time-specific properties of a retry attempt.

Same asResultRetryAlgorithmWithContext, but without methods that accept aRetryingContext. UseResultRetryAlgorithmWithContext instead of this interface when possible.

A result retry algorithm is responsible for the following operations (based on the response returned by the previous attempt or on the thrown exception):

1. Accepting a task for retry so another attempt will be made.
2. Canceling retrying process so the relatedjava.util.concurrent.Future will be canceled.
3. CreatingTimedAttemptSettings for each subsequent retry attempt.

Implementations of this interface receive aRetryingContext that can contain specificRetrySettings and retryable codes that should be used to determine the retry behavior.

Implementations of this interface must be thread-safe.

Context for a retryable operation.

It provides state to individualRetryingFutures via theRetryingExecutor.

A retrying executor is responsible for the following operations:

1. Creating first attemptRetryingFuture, which acts as a facade, hiding from client code the actual execution of scheduled retry attempts.
2. Executing the actualCallable in a retriable context.

This interface is for internal/advanced use only.

ARetryingExecutor that accepts a per-operation context.See Also:RetryingExecutor

Represents a retrying future. This is a facade hiding all the complications of an asynchronous/synchronous execution of a retriable task.

This interface is for advanced/internal use only.

This is part of the server streaming retry api. Its implementers are responsible for tracking the progress of the stream and calculating a request to resume it in case of an error.

Implementations don't have to be threadsafe because all of the calls will be serialized.

Same asTimedRetryAlgorithmWithContext, but without methods that accept aRetryingContext. UseTimedRetryAlgorithmWithContext instead of this interface when possible.

A timed retry algorithm is responsible for the following operations, based on the previous attempt settings and current time:

1. Creating first attemptTimedAttemptSettings.
2. Accepting a task for retry so another attempt will be made.
3. Canceling retrying process so the relatedjava.util.concurrent.Future will be canceled.
4. CreatingTimedAttemptSettings for each subsequent retry attempt.

Implementations of this interface receive aRetryingContext that can contain specificRetrySettings and retryable codes that should be used to determine the retry behavior.

Implementations of this interface must be be thread-save.

PollException is thrown when polling algorithm exceeds total timeout or total number of attempts.

A wrapper exception thrown byServerStreamingAttemptCallable to communicate additional context to theStreamingRetryAlgorithm and to pass the original cancellation stack trace toRetryingServerStreamingCallable.

For internal use only - public for technical reasons.