Namespace com.google.api.gax.retrying (2.7.1)

A basic implementation of ResultRetryAlgorithm. Using this implementation would mean that all exceptions should be retried, all responses should be accepted (including null) 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 throws PollException 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.

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

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 for retry or poll 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 timeout com.google.api.gax.rpc.ApiCallContext#withStreamWaitTimeout(Duration).

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

The retry executor which uses ScheduledExecutorService to schedule an attempt tasks.

This implementation does not manage the lifecycle of the underlying ScheduledExecutorService, so it should be managed outside of this class (like calling the ScheduledExecutorService#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 underlying ScheduledExecutorService.

This class is thread-safe.

A wrapper exception thrown by ServerStreamingAttemptCallable to communicate additional context to the StreamingRetryAlgorithm and to pass the original cancellation stack trace to RetryingServerStreamingCallable.

For internal use only - public for technical reasons.

Simplest implementation of a StreamResumptionStrategy 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 extends RetryAlgorithm to take additional information (provided by ServerStreamingAttemptCallable) 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 as ResultRetryAlgorithmWithContext, but without methods that accept a RetryingContext. Use ResultRetryAlgorithmWithContext 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 related java.util.concurrent.Future will be canceled.
3. Creating TimedAttemptSettings for each subsequent retry attempt.

Implementations of this interface receive a RetryingContext that can contain specific RetrySettings 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 individual RetryingFutures via the RetryingExecutor.

A retrying executor is responsible for the following operations:

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

This interface is for internal/advanced use only.

A RetryingExecutor that accepts a per-operation context.

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 as TimedRetryAlgorithmWithContext, but without methods that accept a RetryingContext. Use TimedRetryAlgorithmWithContext 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 attempt TimedAttemptSettings.
2. Accepting a task for retry so another attempt will be made.
3. Canceling retrying process so the related java.util.concurrent.Future will be canceled.
4. Creating TimedAttemptSettings for each subsequent retry attempt.

Implementations of this interface receive a RetryingContext that can contain specific RetrySettings and retryable codes that should be used to determine the retry behavior.

Implementations of this interface must be be thread-save.