[grpc-io] [gRPC-python] Any examples of using "fork" method of parallelism in gRPC-Python

With the recent launch of grpc-python 1.15.0 version fork method has been enabled with GRPC_ENABLE_FORK_SUPPORT=1 flag, to achieve parallelism. Is there any tutorial/example explaining how to make use of it ? (We have been using single thread approach until now, as performance was degrading

[grpc-io] Re: What to do with a failing TCP client connection?

Thanks for the insight! On Wednesday, September 26, 2018 at 2:08:53 PM UTC-4, Muxi Yan wrote: > > A new connection will be created if (and only if) the channel arguments > are different; otherwise the same connection will be reused. > > On Wednesday, September 19, 2018 at 8:02:07 AM UTC-7,

[grpc-io] Re: Is there a way to tell if Write failed because the msg is too big

Thanks for the response! I am using the async Write. There is no status returned in the call to Write itself. The Next call to the completion queue has no status indication as well, except for the success/failure boolean value. On Wednesday, September 26, 2018 at 2:05:44 PM UTC-4, Muxi Yan

[grpc-io] gRFC L39: Remove grpc_use_signal from core surface API

Discussion thread for gRFC L39: https://github.com/grpc/proposal/pull/106 This gRFC proposes to delete the grpc_use_signal function from the core surface API, as it is no longer useful (gRPC no longer uses signals internally). -- You received this message because you are subscribed to the

[grpc-io] gRFC L40: Node Call Invocation Transformer API

Discussion thread for gRFC L40: https://github.com/grpc/proposal/pull/107 This gRFC proposes a new Client option for modifying how calls are invoked. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving

[grpc-io] Re: What to do with a failing TCP client connection?

A new connection will be created if (and only if) the channel arguments are different; otherwise the same connection will be reused. On Wednesday, September 19, 2018 at 8:02:07 AM UTC-7, grpc_client wrote: > > *Language*: C++ > *gRPC version*: 1.2.5 > *Role*: gRPC client > > A quick question

[grpc-io] Re: Is there a way to tell if Write failed because the msg is too big

AFAIK the error detail should be included in the returned status of the call. On Thursday, September 20, 2018 at 7:22:49 AM UTC-7, dataman wrote: > > > Hi all, > > I am working on an async gRPC client in C++. Due to server limitations we > need to cap the max send msg size in the client. When

[grpc-io] Re: Contributing to gRPC Ruby plugin, questions running tests locally (MacOS, Ruby)

Re: context I'm not clear on what the bug is at this point, or if there is one. If I understand, the issues encountered here were while attempting to reproduce a suspected bug? Re: SETTING UP LOCAL DEVELOPMENT I'm actually surprised that your invocation of "python

Re: [grpc-io] Re: grpc Async Client

Hi mauricio : I'm also using c++ version of gRPC 1.8.x. And I didn't encounter your problem. I spawned 3 instance of server which sleep 3s/1s/1s respectively, and the client start requesting in an asynchronous manner, received response from the last two instances after 1 second , then received

Re: [grpc-io] grpc java biDirectional streaming client retry when onError is called

Hi, I have the same question. How do I know the messages have delivered to the server side? The client can get and store all messages in the interceptor. However I can't get any error if the connection has any problem. Observer.onError can't get any information about sent messages. On