[grpc-io] Re: Using the binder as the transport for gRPC

It seems that InProcessChannelBuilder is using the socket, right ? On Thursday, July 13, 2017 at 5:17:26 AM UTC+8, Carl Mastrangelo wrote: > > gRPC Java's transport is slightly more pluggable than C++. > > Is binder just inprocess? If so, why not use InProcessChannelBuilder? > > On Tuesday,

[grpc-io] Re: Using the binder as the transport for gRPC

gRPC Java's transport is slightly more pluggable than C++. Is binder just inprocess? If so, why not use InProcessChannelBuilder? On Tuesday, July 11, 2017 at 7:26:27 PM UTC-7, song...@gmail.com wrote: > > Hi, > > Thanks for your information. > > 1. why is that possible for gRPC Java not for

[grpc-io] Re: [Java] Collection types and their usage

Responses inline One other thing: Proto fields are typically named singular (dependency rather than dependencies) because the generated code is awkward. Java turns this into getDependencyList(), which reads better then getDependenciesList(). On Tuesday, July 11, 2017 at 9:27:08 AM UTC-7,

[grpc-io] Re: An existing connection was forcibly closed by the remote host

Could you try channel.shutdownNow() instead of shutdown()? I think that logged message is somewhat of a hypochondriac. On Sunday, July 2, 2017 at 9:20:19 PM UTC-7, kesha...@javra.com wrote: > > I using the following environment. > > Windows 7 64 bit. > Java : jdk1.8.0_131 > >

Re: [grpc-io] Re: How to to close BiDi streaming gracefully from C++ server thread (pthr)when c++ client gets aborted.

I'm not sure if TryCancel is the easy way to stop a stream. Calling WritesDone() on client and Finish on server is equally simple. In any case, the recommended way is to do TryCancel() only when you no longer see a point in continuing the call. Also TryCancel is a best-effort call..so Once you do

Re: [grpc-io] Re: Unexpected grpc verbose messages

Fixing PR at https://github.com/grpc/grpc/pull/11770 On Wed, Jul 12, 2017 at 7:10 AM, Noah Eisen wrote: > Ok, I can also repro this pretty easily on my Linux box, and my MacOS > laptop. Might be an issue with when the c core checks the GRPC_VERBOSITY > environment variable.

Re: [grpc-io] Re: Unexpected grpc verbose messages

Ok, I can also repro this pretty easily on my Linux box, and my MacOS laptop. Might be an issue with when the c core checks the GRPC_VERBOSITY environment variable. I'll look into it this morning. On Tue, Jul 11, 2017 at 11:04 PM, 'Julien' via grpc.io < grpc-io@googlegroups.com> wrote: > Hello,

Re: [grpc-io] [Java] Clean way to detect client crash

Hi Eric, Thanks for your idea. Here is how I have implemented it, tell me if this is correct: rpc HeartBeat(stream Void) returns Void; C# Client do: using (var heartBeat = client.HeartBeat(new CallOptions(null, null, channel. ShutdownToken).WithWaitForReady(true))) { await

[grpc-io] Re: Initializing the gRPC.

Can you give an example of the workflow that triggers the problem? We try to hide the initialization behind the creation of some high level C++ objects so that users should not need to worry about explicit initialization. Thanks. On Sunday, June 25, 2017 at 10:45:54 PM UTC-7,

[grpc-io] Re: Unexpected grpc verbose messages

Hello, System is Red Hat Enterprise Linux 6.6, with kernel 2.6.32-642.13.1.el6.x86_64 and gcc 5.2.0. Regards, Julien Le mercredi 12 juillet 2017 00:52:05 UTC+2, ncte...@google.com a écrit : > > What OS are you running on? I will try to repro and look into this > > On Monday, July 3, 2017 at