grpc now supports the following client lib automated retry & resiliency features

[aozmen121]

Feature description

grpc now supports the following client automated retry & resiliency features:

"retryPolicy": {
  "maxAttempts": 4,
  "initialBackoff": "0.1s",
  "maxBackoff": "1s",
  "backoffMultiplier": 2,
  "retryableStatusCodes": [
    "UNAVAILABLE"
  ]
}

See following link with the grpc features, for more info
https://github.com/grpc/proposal/blob/master/A6-client-retries.md

Can we please incorporate this in micronaut-grpc.

[aozmen121]

@graemerocher When can the these features be planned in?
FYI @dstepanov

[graemerocher]

Contributions welcome

[DiogoMurano]

I took a look at the implementation, and it seems not too complex considering the grpc-java as a base. The 'retryPolicy' settings should be inserted into the ManagedChannelBuilder instance that we inject when starting our context, in the Map<String, ?> typing, following the format specified in the cited documentation.

Like this for retry:

"retryPolicy": {
  "maxAttempts": 4,
  "initialBackoff": "0.1s",
  "maxBackoff": "1s",
  "backoffMultiplier": 2,
  "retryableStatusCodes": [
    "UNAVAILABLE"
  ]
}

Or this for multiple simultaneous calls:

"hedgingPolicy": {
  "maxAttempts": 4,
  "hedgingDelay": "0.5s",
  "nonFatalStatusCodes": [
    "UNAVAILABLE",
    "INTERNAL",
    "ABORTED"
  ]
}

Considering this, I believe the effort to implement this efficiently in micronaut-grpc is to receive these settings as 'properties', format them to Map<String, ?>, and insert them into the grpc-java context. We'll leave the rest of the magic to them :)

Does it make sense this way? If there are no objections, I plan to implement it.

grpc-java implementation reference: https://github.com/grpc/grpc-java/blob/f3a1a3ff10ee07383aad3a51afb3fbbc7fe3d0db/examples/src/main/java/io/grpc/examples/retrying/RetryingHelloWorldClient.java