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

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

[grpc-io] Re: fork() support in Python!

Hi Yonatan, Your understanding is correct. The design takes care of not affecting RPCs in parent process due to FD shutdown in the child's post-fork handlers. Child process will recreate its own connection when a Python object (with a gRPC stub inside) inherited from the parent needs to be

[grpc-io] fork() support in Python!

Wow -- I just saw the notes for 16264 , and that 1.15 now supports fork() in Python. This is huge and great news! I just want to make sure I understand how this change works, and in particular what the consequences of the shutdown of the core-level gRPC

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

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

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

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

[grpc-io] Re: Load Balance secure connection

Expanding on this answer further > The data passes through the said proxy. Ok, so that makes sense. So basically: + --> B1 | C ---> P --> B2 | + --> B3 If this diagram doesn't get broke, the issue you have is that the Proxy can't have access to the certs but

[grpc-io] Re: Handshake failed with fatal error SSL_ERROR_SSL: error:14090086:SSL

Two immediate questions;: Did you swap the order of the root cert and the my_cert? When I used openssl verify I had to swap the order. Normally I would call the CA cert the root. I think you need to rename the two certs to each other. The authority you connect to in your client needs to

Re: [grpc-io] grpc for database driver

Ok, so my original statement about being forced to use the ‘streaming rpc’ was the correct way. I thought you said that was the case, but then you offered up what seemed like other solutions that would allow me to use individual rpcs… But then why have the ‘idle time’ - if the connections are

Re: [grpc-io] grpc for database driver

On Wed, Oct 17, 2018 at 11:54 AM robert engels wrote: > Yes, I see how I can re-use the ClientConn across db open requests, the > problem I have is that even if I set a ‘MAX-IDLE’ (and add client code to > ‘ping’ within this interval), I don’t see any method on the server side to > detect when

Re: [grpc-io] grpc for database driver

Thanks for your help. Yes, I see how I can re-use the ClientConn across db open requests, the problem I have is that even if I set a ‘MAX-IDLE’ (and add client code to ‘ping’ within this interval), I don’t see any method on the server side to detect when the connection was dropped - there does

[grpc-io] Re: How to change DSCP value of gRPC packets

Thank you, Srini. On Tuesday, October 16, 2018 at 12:39:41 PM UTC-7, Srini Polavarapu wrote: > > Hi, > > There is no API in gRPC Python to set DSCP value. Please open an issue > to track this although this > would be low priority for us. > > Thanks. > >

Re: [grpc-io] grpc for database driver

On Wed, Oct 17, 2018 at 8:58 AM wrote: > When reviewing the API docs, it was the only way I could implement a > "connection", otherwise for each rpc call, a new connection (tcp) is made > for each request > No. A stream is the only way to guarantee multiple requests go to the same server, but

[grpc-io] grpc for database driver

Hello, I wrote a database driver using Go and grpc. I ended up using the "streaming" rpc because that was the only way it seems to have a "stable connection". When reviewing the API docs, it was the only way I could implement a "connection", otherwise for each rpc call, a new connection (tcp)

[grpc-io] Handshake failed with fatal error SSL_ERROR_SSL: error:14090086:SSL

Hi, I am trying to setup a gRPC client and server example on WSL with SSL (server authentication only) I created the following files (following this tutorial: https://jsherz.com/grpc/node/nodejs/mutual/authentication/ssl/2017/10/27/grpc-node-with-mutual-auth.html) *my_root_cert.crt*

[grpc-io] Re: [go-nuts] go-grpc question

Hi, my understanding, and it seems to be correct in testing is that grpc always makes a new connection (via tcp) due to load balancing. The only way I’ve been able to get grpc to use a single connection is if I use the “streaming” mode. What am I doing wrong then? > On Oct 17, 2018, at 8:24

[grpc-io] Re: [go-nuts] go-grpc question

*+grpc-io@googlegroups.com * *moving golang-n...@googlegroups.com to BCC* In general, connections are not cheap, but stubs are. Actual implementations for some languages differ, but Go complies with this. What that means is that, generally speaking, you should not try creating the

Re: [grpc-io] Async C++ service with multiple methods

Am Dienstag, 16. Oktober 2018 00:40:58 UTC+2 schrieb Christopher Warrington - MSFT: > > > By imposing these restrictions atop the gRPC++ library, we were able to > simplify implementation of async services [8]: > class GreeterServiceImpl final : public Greeter::Service > { > public:

Re: [grpc-io] Async C++ service with multiple methods

Hello Nathan, Am Montag, 15. Oktober 2018 17:54:48 UTC+2 schrieb Nathan Prat: > > How can you use CRTP? I tried it this way, but after `cq_->Next` you can't > static_cast to a templated class. Or am I missing something? > I have a mixture now of virtual inheritance and CRTP. Basically, one

[grpc-io] Re: gRPCLB in gRPC Java 1.14

On Tuesday, 31 July 2018 20:30:41 UTC+2, Carl Mastrangelo wrote: > There will be upcoming documentation on the exact way to configure this, > but this is being announced here for interested parties to try it out and > answer any questions. > (...) and there currently isn't a load reporter. I