Ok, so my original statement about being forced to use the ‘streaming rpc’ was the correct way. I thought you said that was the case, but then you offered up what seemed like other solutions that would allow me to use individual rpcs…
But then why have the ‘idle time’ - if the connections are terminated when there are not more rpcs ? I am not sure why the server process can’t be notified when a connection is “terminated” due to idle timeout (or any other reason - like IO errors) - so it can clean up cached resources - doesn’t make a lot of sense to me? > On Oct 17, 2018, at 2:01 PM, Eric Anderson <[email protected]> wrote: > > On Wed, Oct 17, 2018 at 11:54 AM robert engels <[email protected] > <mailto:[email protected]>> wrote: > 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 ? > > There's no API to know when the connection is dropped. All the semantics are > per-RPC. RPC's can be "cancelled." Normally the connection is only dropped if > there are no RPCs. But if there is an I/O error or similar, then the RPCs > will be treated as cancelled. You can be notified when the RPC is cancelled > via Context.Done(). -- 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/9C59B815-3941-4361-B953-B68AA5734C0A%40earthlink.net. For more options, visit https://groups.google.com/d/optout.
