Application-level Retry Policy

[mic...@improbable.io]

Hi,

We're happily using gRPC in production, and it is a breathe of fresh air for providing public APIs to users (when combined with gRPC Gateway).

We've recently introduced rate limiting on our APIs, that respond that returns a Status.UNAVAILABLE on calls that are limited (we did consider Status.RESOURCE_EXHAUSTED, but we also use it for APIs with quota, where immediate retries won't help). Unfortunately, while the server-side implementation is easy, the client side became really messy.

We have to manually wrap all calls in backoff retry strategies. This is especially painful for streaming calls. While there is work related to connectitivty retries (https://github.com/grpc/grpc/issues/5377), there is absolutely no logic around retries based on responses. Having to write backoff strategies in user application logic, makes the logic polluted with something that is otherwise networking code.

Is gRPC planning some form of support for application-level retries? Maybe a RetryPolicy that can be injected into a Stub on creation?

Cheers,

Michal

Head of Infrastructure

Improbable

[no...@google.com]

Hey gRPC team,

What's you opinion on this? Should app code be explicit about retries or it can be somewhat transparent in a retry policy or something?

Would you consider to implement a hook where developers can inject retries?

Thanks,

[Eric Anderson]

On Mon, Apr 11, 2016 at 9:25 AM, nodir via grpc.io <grp...@googlegroups.com> wrote:

What's you opinion on this? Should app code be explicit about retries or it can be somewhat transparent in a retry policy or something?

At present, the app needs to explicitly handle retries. Retries weren't planned to be a 1.0 feature.

There's been multiple retry interceptors written for Java, which the Google part of the team hasn't had enough time to give proper attention to, so I don't think either will be in the next release (the one planned for... last week). If using Java, you can probably copy it to your application for the moment.

Would you consider to implement a hook where developers can inject retries?

 

On Saturday, March 19, 2016 at 7:54:18 AM UTC-7, mic...@improbable.io wrote:

Is gRPC planning some form of support for application-level retries? Maybe a RetryPolicy that can be injected into a Stub on creation?

We do want to support client-side retries, but they are also non-trivial. We've delayed in handling them because we don't yet have the time and because that are 1) generally considerably easier to do in applications short-term (because the app can assume more) and 2) difficult to get the right API.

There's a very rough idea of what some of us were envisioning on a cross-language API. I think overall gRPC is still a ways away from knowing exactly how things will look, but it's on many people's radar.