Thanks for your help. Yes, I see how I can re-use the ClientConn across db open requests, the problem I have is that even if I set a ‘MAX-IDLE’ (and add client code to ‘ping’ within this interval), I don’t see any method on the server side to detect when the connection was dropped - there does not seem to be a callback (or channel) in the Go api ?
> On Oct 17, 2018, at 12:01 PM, 'Eric Anderson' via grpc.io > <[email protected]> wrote: > > On Wed, Oct 17, 2018 at 8:58 AM <[email protected] > <mailto:[email protected]>> wrote: > When reviewing the API docs, it was the only way I could implement a > "connection", otherwise for each rpc call, a new connection (tcp) is made for > each request > > No. A stream is the only way to guarantee multiple requests go to the same > server, but normal RPCs can/do reuse connections. Since gRPC is using HTTP/2, > as long as you re-use the ClientConn gRPC is able to issue lots of RPCs on > the same connection, even concurrently. > > ClientConn may create more than one connection, but this is for things like > load balancing, where you need distribute traffic to multiple backends. But > by default, ClientConn will have a single connection it will use for all > RPCs, and automatically replace that connection if something is wrong with it. > > and there is no "lifecycle" events on the server side to determine when a > connection is dead, etc. > > Yes, this is on purpose. The vast majority of use cases should have no need > for this level of API. We do provide mechanisms > <https://github.com/grpc/proposal/blob/master/A9-server-side-conn-mgt.md> to > detect broken connections and release idle connections, however. (That is > implemented in Go) > > Is it also a possibility that if I use a TLS connection, then the grpc > connection will be stable across rpc calls ? > > Yes. If a call fails, that shouldn't impact the TLS connection. Simply > continue using the same ClientConn and gRPC should manage the connection for > you. > > You can see the code at github.com/robaho/keydbr > <http://github.com/robaho/keydbr> > > I would not suggest closing the ClientConn on error. Even if there is a > failure with the connection and RPCs fail, the ClientConn will properly > reconnect. It will also do things like exponential backoff on repeated > connection failures to avoid cascading failures. > > I suggest sharing a single ClientConn per `addr` (in your app) as much as > possible. > > -- > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/grpc-io > <https://groups.google.com/group/grpc-io>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oPKeLnEso9Sypc-O_KAT_d0i6g63%3D2pjBqmvj-J21CsVg%40mail.gmail.com > > <https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oPKeLnEso9Sypc-O_KAT_d0i6g63%3D2pjBqmvj-J21CsVg%40mail.gmail.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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/883A600A-8C04-4C05-A29F-7A5D7C35A990%40earthlink.net. For more options, visit https://groups.google.com/d/optout.
