gRFC L42 Adding wait-for-ready semantics

[li...@google.com]

This thread is for the proposal at https://github.com/grpc/proposal/pull/112.

Full gRFC at https://github.com/lidizheng/proposal/blob/master/L42-metadata-flags.md.

The purpose of this gRFC is to enable gRPC Python client to utilize the “Wait For Ready” mechanism provided by C-Core, which underlying is to utilize the initial metadata flags. This mechanism can later be used to support future metadata flags. 

Definition of Wait For Ready semantics

> If an RPC is issued but the channel is in TRANSIENT_FAILURE or SHUTDOWN states, the RPC is unable to be transmitted promptly. By default, gRPC implementations SHOULD fail such RPCs immediately. This is known as "fail fast," but the usage of the term is historical. RPCs SHOULD NOT fail as a result of the channel being in other states (CONNECTING, READY, or IDLE).
> 
> gRPC implementations MAY provide a per-RPC option to not fail RPCs as a result of the channel being in TRANSIENT_FAILURE state. Instead, the implementation queues the RPCs until the channel is READY. This is known as "wait for ready." The RPCs SHOULD still fail before READY if there are unrelated reasons, such as the channel is SHUTDOWN or the RPC's deadline is reached.
> 
> From https://github.com/grpc/grpc/blob/master/doc/wait-for-ready.md 

Proposal

* Add an optional `wait_for_ready` variable to `MultiCallable` classes initialization methods. Default `None`, accept `bool`.
* Per RPC level `wait_for_ready` variable can override upper level.
* Import initial metadata flags constants from `grpc_types.h` to `grpc.pxi`.
* (Suggesting) Add an optional `wait_for_ready` variable to `Channel` class initialization method. Default `None`, accept `bool`.

[Eric Anderson]

On Wed, Oct 17, 2018 at 4:52 PM lidiz via grpc.io <grp...@googlegroups.com> wrote:

* (Suggesting) Add an optional `wait_for_ready` variable to `Channel` class initialization method. Default `None`, accept `bool`.

Please don't. wait_for_ready changes the semantics of the call enough that you don't ever want to wonder what the current value is. You need the wait_for_ready configuration very close to the code doing the RPC. 

[Lidi Zheng]

Got it, thanks.

Do you know why Python version doesn't have the a subset config class?

Should this feature be implemented in that way?

It seems that will be inconsistent with previous `timeout` variable.

On Wed, Oct 17, 2018 at 5:53 PM Eric Anderson <ej...@google.com> wrote:

On Wed, Oct 17, 2018 at 5:49 PM Lidi Zheng <li...@google.com> wrote:

Both designs are valid for me, it can be convenient when users want an easy way to adopt this logic to all of their RPC calls. Especially for users who doesn't implement fallback logic for RPC calls.

It's dangerous because users "pay" for the complexity even if they don't use the feature. Because now they (as us when we help them debug) have to determine what the setting is.

It has the potential to replace the existing `grpc.channel_ready_future` function.

Definitely. +1. But that is true in either case I think.

 

And it can make the logic of Python API more similar to `client_context` in C++ or `CallOptions` in Java and Golang.

Except in C++ and Java those settings don't apply to the entire Channel. They may apply to a subset of calls, but the user has good control over what.

[Mehrdad Afshari]

I strongly concur with Eric. As we also discussed offline, I am against the per-channel wait_for_ready value for two primary reasons:

1. we should be conservative when adding APIs, as we can easily add but cannot remove APIs. If this turns out to be a massive user concern, we can resolve it later. 

2. additional complexity of defining the semantics when per call and per channel values are present (or absent), which ties closely to Eric’s concern of non-obviousness of behavior. 

--
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 post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAMC1%3Djezna9YkAmRuiJQNL5WbDjmxSTA7aOz756y7R-1DQa%2B6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Anderson]

On Wed, Oct 17, 2018 at 6:00 PM Lidi Zheng <li...@google.com> wrote:

Do you know why Python version doesn't have the a subset config class?

It wasn't a requirement. It wasn't even that important during Java's design.

Should this feature be implemented in that way?

Unclear. In the design process I'd default to following in the footsteps of timeout. However, it is possible that the "use named arguments" doesn't scale well to many options and if that is becoming a risk then you may consider alternatives. I don't know the Python API well enough to say.

[Lidi Zheng]

Thanks for your input. It's always good to know the reasoning for each language's implementation.