what's the difference between enableRetry and waitForReady?

[Elhanan Maayan]

from my POV those seem to be identical except for the fact that waitForReady doesn't execute calls until channel is read while enableRetry does, why should that matter? (if i'm using steaming rpc)

[Eric Gribkoff]

A major difference is that, if retries are enabled, the server can reply with an error code that's been configured as retryable and the client can retry the RPC.

On Thu, Dec 26, 2019 at 2:07 AM Elhanan Maayan <elh.m...@gmail.com> wrote:

from my POV those seem to be identical except for the fact that waitForReady doesn't execute calls until channel is read while enableRetry does, why should that matter? (if i'm using steaming rpc)

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/2ea04be3-a7c9-44c0-9539-00ae7394a6f8%40googlegroups.com.

[Elhanan Maayan]

will i get this to see this error code? i mean let's assume i've configured it to have several retriable error code, can my application receive any call back about it? 

[Eric Gribkoff]

No, if you have configured automatic retries for that error code, it will be automatically retried. The spec for this is at https://github.com/grpc/proposal/blob/master/A6-client-retries.md. Avoiding a callback to the user while the RPC is automatically being tried was a explicit goal of the design: if the client needs to alter its behavior due to retries then it should not be using gRPC's retry support and should instead have retry logic implemented in the application layer.  However, in the metadata of the RPC on the clientside (when it eventually succeeds or fails), gRPC will insert an integer value for the `grpc-previous-rpc-attempts` key that lets you know how many attempts were made, but not their error codes.

[Elhanan Maayan]

what if the client doesn't want a different retry logic but simply interested in logging, auditing  and dashboard functionality ? 

On Thursday, December 26, 2019 at 11:07:54 PM UTC+2, Eric Gribkoff wrote:

No, if you have configured automatic retries for that error code, it will be automatically retried. The spec for this is at https://github.com/grpc/proposal/blob/master/A6-client-retries.md. Avoiding a callback to the user while the RPC is automatically being tried was a explicit goal of the design: if the client needs to alter its behavior due to retries then it should not be using gRPC's retry support and should instead have retry logic implemented in the application layer.  However, in the metadata of the RPC on the clientside (when it eventually succeeds or fails), gRPC will insert an integer value for the `grpc-previous-rpc-attempts` key that lets you know how many attempts were made, but not their error codes.

On Thu, Dec 26, 2019 at 12:58 PM Elhanan Maayan <elh....@gmail.com> wrote:

will i get this to see this error code? i mean let's assume i've configured it to have several retriable error code, can my application receive any call back about it? 

On Thu, Dec 26, 2019 at 10:54 PM Eric Gribkoff <ericgr...@google.com> wrote:

A major difference is that, if retries are enabled, the server can reply with an error code that's been configured as retryable and the client can retry the RPC.

On Thu, Dec 26, 2019 at 2:07 AM Elhanan Maayan <elh....@gmail.com> wrote:

from my POV those seem to be identical except for the fact that waitForReady doesn't execute calls until channel is read while enableRetry does, why should that matter? (if i'm using steaming rpc)

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.

To unsubscribe from this group and stop receiving emails from it, send an email to grp...@googlegroups.com.