Motivation

...

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.

Discussion Links

• https://

...

• lists.apache.org/thread/w2pqdz2p9jn6rqq2lw0zv9ohv0o7m9wx

Reference Links

• Code sample: https://github.com/apache/ignite/pull/9586

Tickets

• Cassandra retry policy: https://docs.datastax.com/en/drivers/java/2.0/com/datastax/driver/core/policies/RetryPolicy.html
• gRPC Retry Policy  (an example of similar approach)
  • https://devblogs.microsoft.com/dotnet/grpc-in-dotnet-6/#transient-fault-handling-with-retries
  • https://docs.microsoft.com/en-us/aspnet/core/grpc/retries?view=aspnetcore-6.0

Tickets