Partial answers: Callers don't drop connections due to timeouts. Rpcs can drop due to timeouts, but not really connections. In the event that the RPC times out, the client-side loadbalancer will decide if the RPC can be rescheduled onto a new connection. gRPC comes with two load balancers by default: PickFirst and RoundRobin. PickFirst prefers to use a single connection, even if there are multiple backends. Pick first is also the default. Round Robin spreads load evenly across backends, and can send new RPCs to non failing connections.
I can't comment on the C++ API, unfortunately. On Thursday, January 31, 2019 at 12:54:19 AM UTC-8, Stephan Menzel wrote: > > Hello group, > > I am in the process of transforming a number of gRPC services to an async > approach. To this end, I have implemented a base architecture for my calls, > starting out with the async server example in the code and extending it > with a template base class for my calls. Unlike the example, the actual > work is done in a workerthread running a number of fibers where I post all > the work into. > > As I get along transforming all the calls a question arises that puzzled > me for quite some time and that I like to find an answer for in order to > get my implementation stabilized. I am referring to this example: > https://github.com/grpc/grpc/blob/master/examples/cpp/helloworld/greeter_async_server.cc > > The question is: What happens when things go south? > > For example, when the caller drops the connection because it runs into its > timeout. What happens to the call? Will it somehow be shut down? And how do > I notice that? Since my actual work is happening in another thread I need > to understand the lifecycle of the object better. > > The same goes for the call itself to timeout. Some of my implementations > involve blocking file IO and other stuff that may exceed a timeout I am > setting myself. Am I right assuming that I'm supposed to call Finish() > anyway? And would I be able to tell Finish() that this call is faulty or > would I use the actual response payload to relay this information? > > What other error conditions should I take care of that the example doesn't > cover? I'm thinking unparseable calls? Unimplemented methods? Anything > really. > > Can anyone shed some light on this? > > Best regards... > > Stephan > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/ad438a39-85a1-48e5-bf2f-d00a519f69ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
