[grpc-io] Re: Disable application protocol negotiation by usage of nginx ssl termination

This is tangential to the discussion (and I don't have recent experience with Nginx and HTTP/2), but it seems like at least till a year ago or so, Nginx didn't support HTTP/2 trailer proxying that is used by gRPC. Has that situation improved on that dimension? If not, that might remain an issue

[grpc-io] gRFC L12: C# Client and Server Interceptor Support

I've submitted a gRFC for adding C# client and server interceptors: https://github.com/grpc/proposal/pull/38 Implementation: https://github.com/grpc/grpc/pull/12613 Feedback is appreciated. Per the gRFC process, please keep discussion in this thread. Cheers, Mehrdad -- You received this mess

[grpc-io] gRFC L13: Python Client and Server Interceptors

I've submitted a gRFC for supporting client and server interceptors in Python: https://github.com/grpc/proposal/pull/39 Implementation: https://github.com/grpc/grpc/pull/12778 Feedback is appreciated. Per the gRFC process, please keep discussion in this thread. -- You received this message bec

Re: [grpc-io] Python: returning an empty typed response during error handling

+nathan...@google.com We were just discussing this with Nathaniel and the primary reason behind that API contract constraint, in addition to future-proofing by being conservative, is to prevent the user from accidentally not returning the return value of an OK-status RPC and having Python return N

Re: [grpc-io] Re: gRFC L13: Python Client and Server Interceptors

Re the pattern, the basic idea adopted here, as in Go and C#, is to be able to add hooks to intercept all invocations before reaching the RPC core. To intercept "events", the interceptor would optionally decorate the return value from itself, to be able to inject code during the control-flow. I am

[grpc-io] Re: gRFC L12: C# Client and Server Interceptor Support

General comments on the proposal are preferred here. Comments that are tied to on the implementation are probably easier addressed on the pull request of the implementation, i.e. https://github.com/grpc/grpc/pull/12613 On Wednesday, October 11, 2017 at 10:25:52 AM UTC-7, Christopher Warrington

[grpc-io] Re: gRFC L13: Python Client and Server Interceptors

I will clarify the order in the proposal, but the intended behavior is in order they are specified, so if you are observing otherwise, that might be a bug in the PR. Will check. On Tuesday, October 10, 2017 at 5:54:31 PM UTC-7, Amit Saha wrote: > > > > On Monday, October 2, 2017 at 11:07:11 PM U

Re: [grpc-io] Re: gRFC L12: C# Client and Server Interceptor Support

Thanks Christopher for comments and Jan for some answers. I should update the proposal since there were some changes in the design, but to add to Jan's answer. 1. We will likely drop this feature in the initial pull request and add it later. 2. Yes, it will needed to be registered generically. Ot

Re: [grpc-io] Re: gRFC L12: C# Client and Server Interceptor Support

I happened to change the server side design to alleviate the concerns re (3): https://github.com/grpc/grpc/pull/12613/commits/c1e9d1dd72f969d539274b0f7b31ae3bb4cc7a5b The trade-off is one additional null check in the fast path where no interceptors are present, which is probably negligible and wor

[grpc-io] gRPC Core 1.8 is out

I'm happy to announce that gRPC Core 1.8 is out! This extends to C++, Python (v1.8.1 ), Node.js, C# and Objective-C. Refer to the release notes for detai

[grpc-io] Re: building gRPC go on AIX

I think there might be an issue with Go fetching the URL. You can try cloning the git repository directly (github.com/grpc/grpc-go) under the right path (google.golang.org/grpc) in your $GOPATH/src. You probably need to recursively do this for all the dependencies as well. Unfortunately we don'

[grpc-io] Re: [python]How to run python packages with gprc

Please follow the greeter example, specifically replacing the body of SayHello with your own code to execute the arbitrary code you want: https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_server.py#L30 On Tuesday, January 9, 2018 at 6:39:26 PM UTC-8, he...@snaps.com wro

Re: [grpc-io] Re: building gRPC go on AIX

Thanks for letting us know! On Wed, Jan 17, 2018 at 11:00 AM wrote: > I solved the issue by installing ca-certificates. > > -Aman > > On Wednesday, January 17, 2018 at 10:39:46 AM UTC-8, Mehrdad Afshari wrote: >> >> I think there might be an issue with Go fetching the URL. You can try >> clonin

[grpc-io] gRPC Core 1.9 "glossy" has been released!

I'm thrilled to announce that gRPC Core 1.9 has been released! This extends to C++, Python, C# and Objective-C. Ruby and Node.js packages will follow soon. Refer to the release notes for details

[grpc-io] gRPC Core 1.10.0 "glamorous" has been released

I'm excited to announce that gRPC Core 1.10.0 (*glamorous *) has been released! This extends to C++, Python, C# and Ruby. Objective-C, PHP and Node.js packages will follow soon. Refer

[grpc-io] Re: Rendezvous of RPC that terminated with StatusCode.UNIMPLEMENTED

Can you give us a minimal reproduction case for the server/client? Even better, is it possible to reproduce it with one of our examples (greeter or route guide)? Thanks! On Friday, March 16, 2018 at 8:51:10 AM UTC-7, mail...@gmail.com wrote: > > Hi , > > I have a gRPC server written in gola

[grpc-io] Re: Rendezvous of RPC that terminated with StatusCode.UNIMPLEMENTED

Can you please send us a minimal reproduction case? Ideally if you could reproduce it with the examples provided (helloworld, route_guide) it'd be great. [P.S. I sent this message a couple days back, but looking at the Groups UI, I don't see it and instead see "2 messages have been deleted", s

[grpc-io] gRPC Core 1.11.0 "gorgeous" has been released

I'm thrilled to announce that gRPC Core 1.11.0 (*gorgeous *) has been released! This extends to C++, C#, Python, Ruby, Objective-C, PHP and Node.js. Refer to the release notes

[grpc-io] Re: Building grpcio-python without recompiling core files

We would love to at some point be able to build gRPC Python properly with Bazel. Last time I checked the blocker seemed to be lack of Cython support, so if you could send us a PR for to build with Bazel, we would love that! Barring that, if there's a sensible step to make the Python setup.py mor

[grpc-io] gRPC Core 1.12.0 "glorious" has been released

I'm incredibly excited to announce that gRPC Core 1.12.0 (*glorious )* has been released! This extends to C++, C#, Python, Ruby, Objective-C, PHP, and Node.js. Please refer to the rel

[grpc-io] Early Access Program for gRPC Nightlies (daily package builds for C#, Python, PHP, Ruby, Objective-C, and Node.js)

Hi, As gRPC gets used more and more as the de facto standard RPC framework in various places, to ease testing for users and enhance the quality of gRPC, and to minimize disruption to mission critical applications due to unanticipated regressions, we intend to supplement the existing Release Candid

Re: [grpc-io] Handling errors from streams in python

Can you please share a minimal client code that exhibits the behavior? On Tue, Aug 21, 2018 at 6:22 AM wrote: > Hi, > > I've been trying ascertain the correct way to handle error behaviour from > streaming endpoints. > > My code effectively does the following: > > service MyService { > rpc S

[grpc-io] Re: has type , but expected one of: ((,),)

Can you share your proto message definition? On Wednesday, August 15, 2018 at 5:25:37 PM UTC-7, mken...@gmail.com wrote: > > Hello All, using python 3 the self.stub.filter_add() call below receives > the following Traceback. It was my understanding the json.dumps() would > correct this, but do

[grpc-io] Re: Benchmarking Python-based gRPC applications

There's not an official framework from gRPC Python, although you can look at the performance benchmark scripts in our repository to get some ideas. On Wednesday, September 12, 2018 at 3:06:26 AM UTC-7, Harsha Adiga wrote: > > We've a few Python-based gRPC applications, and we want to do performan

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 later.

Re: [grpc-io] gRFC L58: Async API for gRPC Python

> 4. Simultaneous read and write is prohibited in C-Core I'm not aware of that C-Core rule before. I have to investigate to talk more. Just to clarify, the restriction is at most 1 pending write and 1 pending read. You can certainly read and write concurrently (and you should definitely allow this

Re: [grpc-io] gRFC L58: Async API for gRPC Python

Hi Lidi, Thanks for the update. Let's start with the core packaging strategy first. I am still perplexed about the general packaging approach and which problems it'd solve. First, keeping the stubs interface intact and making passing a different type of channel to them return a totally different r