Re: [grpc-io] Re: Grpc completion queue types

Thanks for the summary, I'm starting an initiative to analyze how Grpc can be implemented on top of Asyncio. One of the starting points is the current implementation of node-grpc, that relays on grpc_completion_queue_next [1] to achieve the needed cooperation without blocking the loop. The usage

[grpc-io] gRFC L35: add getAuthContext method in Node

https://github.com/grpc/proposal/pull/94 -- 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 gr

[grpc-io] Re: Grpc completion queue types

On Tuesday, August 21, 2018 at 3:28:24 AM UTC-7, Pau Freixes wrote: > I've realized reading the current Grpc code that exists [1] other > alternatives to the completion queue next, the pluck and the callback > one. > > I've been trying to seek some information, or usage, of these > alternatives an

[grpc-io] Is there way I can create a secured channel from already existing socket FD.

I have a use case where I already have a TCP connection between the client and server and I have to use the same socket descriptors to establish a grpc channel which I did with the help of posix call " *AddInsecureChannelFromFd*". My question here is it possible to have a secured channel. If yes

Re: [grpc-io] if we switch from netty to okttp in a non-android project, is there any potential different?

Hi! We run gRPC on SmartOS (ie. Illumos / Solaris based OS) on multiple production systems with Netty with no problems whatsoever. What kind of problems are you experiencing on Solaris and which version of Solaris are you running? Kind regards, Jasper On Tuesday, 21 August 2018 21:05:54 UTC+

Re: [grpc-io] if we switch from netty to okttp in a non-android project, is there any potential different?

Hi Eric, Thank you so much for your reply! We have some Solaris machine, in which seem we cannot use netty, so we would like to switch to okhttp. On Monday, August 20, 2018 at 7:58:08 AM UTC-7, Eric Anderson wrote: > > grpc-okhttp works fine on regular, non-Android Java versions. Security is >

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

So, this is the unit test code that fails (the stub and server are initialized in the setUp): def test_list_invalid(self): request = service_pb2.Request() with self.assertRaises(expected_exception=grpc.RpcError) as error: for _ in self.stub.StreamEndpoint(request):

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] Handling errors from streams in python

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 StreamEndpoint(Request) returns (stream Response) } message Request { repeated string query_ids = 1; } message Response {

[grpc-io] Grpc completion queue types

Hi, I've realized reading the current Grpc code that exists [1] other alternatives to the completion queue next, the pluck and the callback one. I've been trying to seek some information, or usage, of these alternatives and I found nothing. I'm wondering why and behind what circumstances are the

Re: [grpc-io] Re: CSharpGrpcGenerator: document additiona flags

Thanks! Il mar 21 ago 2018, 12:17 'Jan Tattermusch' via grpc.io < grpc-io@googlegroups.com> ha scritto: > I filed https://github.com/grpc/grpc/issues/16411. > > On Thursday, August 9, 2018 at 2:00:03 PM UTC+2, gianmarco...@gmail.com > wrote: >> >> Hi, >> >> by looking at the csharp_plugin.cc sour

[grpc-io] Re: CSharpGrpcGenerator: document additiona flags

I filed https://github.com/grpc/grpc/issues/16411. On Thursday, August 9, 2018 at 2:00:03 PM UTC+2, gianmarco...@gmail.com wrote: > > Hi, > > by looking at the csharp_plugin.cc source code >