Re: [grpc-io] gRFC L42 Adding wait-for-ready semantics

2018-10-18 Thread 'Lidi Zheng' via grpc.io 
Thanks for your input. It's always good to know the reasoning for each
language's implementation.

On Thu, Oct 18, 2018 at 8:22 AM Eric Anderson  wrote:

> On Wed, Oct 17, 2018 at 6:00 PM Lidi Zheng  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.
>
> It seems that will be inconsistent with previous `timeout` variable.
>>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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%3DjctyPr57QJ3azBZFOHHiZSjVQHVb7zJ-dzRXjmgWcCKiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] gRFC L42 Adding wait-for-ready semantics

2018-10-18 Thread 'Eric Anderson' via grpc.io 
On Wed, Oct 17, 2018 at 6:00 PM Lidi Zheng  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.

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/CA%2B4M1oPAG1T03wyEfPn2RrvzC%3DOxMGTC1R-M9BhSq%3D4z0Xpwug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] gRFC L42 Adding wait-for-ready semantics

2018-10-17 Thread 'Mehrdad Afshari' via grpc.io 
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.

On Wed, Oct 17, 2018 at 6:00 PM 'Lidi Zheng' via grpc.io <
grpc-io@googlegroups.com> wrote:

> 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  wrote:
>
>> On Wed, Oct 17, 2018 at 5:49 PM Lidi Zheng  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.
>>
>>
>>>
>>> On Wed, Oct 17, 2018 at 5:20 PM Eric Anderson  wrote:
>>>
 On Wed, Oct 17, 2018 at 4:52 PM lidiz via grpc.io <
 grpc-io@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.

>>> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to grpc-io@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.
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/CABdARdBMAhqKoQP8_cFW0%3D4WP3K6M_a-hRkxRv58KMciTby79g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] gRFC L42 Adding wait-for-ready semantics

2018-10-17 Thread 'Lidi Zheng' via grpc.io 
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  wrote:

> On Wed, Oct 17, 2018 at 5:49 PM Lidi Zheng  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.
>
>
>>
>> On Wed, Oct 17, 2018 at 5:20 PM Eric Anderson  wrote:
>>
>>> On Wed, Oct 17, 2018 at 4:52 PM lidiz via grpc.io <
>>> grpc-io@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.
>>>
>>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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.

Re: [grpc-io] gRFC L42 Adding wait-for-ready semantics

2018-10-17 Thread 'Eric Anderson' via grpc.io 
On Wed, Oct 17, 2018 at 4:52 PM lidiz via grpc.io 
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.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/CA%2B4M1oN6hrx%2BDgwpHJAG1cN%3DUkunK%3DhFvR5%3Dysz%2BPwsYBDaQsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

[grpc-io] gRFC L42 Adding wait-for-ready semantics

2018-10-17 Thread lidiz via grpc.io 
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`.


-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@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/31981f51-f613-4e5b-b484-8d592db61574%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.