Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

All changes are on the client side, server is not affected.

1. Add ClientConfiguration.retryPolicy property. By default, there is no retry.

2. Introduce  Introduce ClientRetryPolicy interface

...

Code Block
languagejava
titleClientRetryPolicy.java
/**
 * Client retry policy determines whether client operations that have failed due to a connection issue should be retried.
 */
public interface ClientRetryPolicy {
    /**
     * Gets a value indicating whether a client operation that has failed due to a connection issue should be retried.
     *
     * @param client Ignite client instance.
     * @param operationType Operation type.
     * @param iteration Current iteration index (greater or equal to 0).
     * @param exception Exception that caused the operation to fail.
     * @return {@code true} if the operation should be retried on another connection, {@code false} otherwise.
     */
    public boolean shouldRetry(IgniteClient client, ClientOperationType operationType, int iteration, ClientConnectionException exception);
}


23. Provide predefined implementations, for example: ClientRetryAllPolicy, ClientRetryReadPolicy, ClientRetryIdempotentPolicy3. Add corresponding property to the client configuration.


Usage example:

Code Block
languagejava
ClientConfiguration cfg = new ClientConfiguration()
        .setRetryPolicy(new ClientRetryReadPolicy());

Ignition.startClient(cfg);


Cross-Language Support

An interface is a good choice for Java and C# thin clients. For other languages, like C++ and Python, we may consider a different approach, such as a callback or a function pointer.

Risks and Assumptions

Ideally, we could pass more information to the shouldRetry method: cache keys and values, SQL query text, and so on, according to the operation at hand. However, this will require extra heap allocations - for every client method call, we'll need to store the arguments somewhere. This means overhead for the entire thin client API, which is not acceptable. We could also make this behavior optional with a property like ClientRetryPolicy.requiresArguments. For now, this is considered out of scope.

...