Interface RetryConfig

Configuration for operation retries, which is set as retry.

When an operation fails with NoSQLError or its subclass, the driver has an option to retry the operation automatically, transparently to the application. The operation may be retried multiple times until the operation timeout is reached. The driver may only retry the operations that failed with retryable ErrorCode (see errorCode). Whether the operation is retried and how depends on the what RetryHandler is used. Retry handler is an object that provides two properties/methods: doRetry that determines whether the operation should be retried at given time and delay that determines how long to wait between successive retries.

RetryConfig object may contain RetryHandler and applicable parameters customize that retry handler. Unless application sets its own RetryHandler, the driver will use default retry handler which is suitable for most applications. Default RetryHandler works as follows:

Whether the operation is retried depends on:

• Whether the error is retryable as mentioned above. This is the case for any RetryHandler. Default RetryHandler has special handling for INVALID_AUTHORIZATION, see the description of that error code for details.
• Type of the operation. In general, only data operations are retried, not DDL or metadata operations (such as listTables or getIndexes). However, if DDL operation caused OPERATION_LIMIT_EXCEEDED. the operation will be retried with large delay as described below.
• Whether the limit on the number of retries has been reached as configured by maxRetries property.

For retry delay, an exponential backoff algorithm is used. The delay starts with baseDelay and then doubles on successive retries. In addition a random value between 0 and baseDelay is added to this result.

Exceptions to this are:

• If DDL operation resulted in OPERATION_LIMIT_EXCEEDED because of more stringent system limits for control operations, a much larger delay is needed to retry the operation. In this case the exponential backoff algorithm will start with a large delay of controlOpBaseDelay. You may customize this value depending on what limits the system has for DDL operations. You may disable automatic retries for this error by setting controlOpBaseDelay to null.
• Network errors (see NETWORK_ERROR) and errors caused by unavailability of security information (see SECURITY_INFO_UNAVAILABLE) are always retried regardless of the number of retries reached without regard to maxRetries. As for other errors, the retries are stopped when operation timeout is reached that results in NoSQLTimeoutError.
• When the retry is caused by unavailability of security information as determined by SECURITY_INFO_UNAVAILABLE the algorithm starts with constant delay of secInfoBaseDelay for a maximum number of retries secInfoNumBackoff and then switches to exponential backoff algorithm described above also starting with secInfoBaseDelay. You can set secInfoNumBackoff to 0 to start exponential backoff algorithm immediately.

You may customize the default retry handler by overriding the values of any properties mentioned above.