That's looks great, thanks! 2017-03-22 0:04 GMT+01:00 'Menghan Li' via grpc.io <[email protected] >:
> Client side keepalive support is merged in https://github.com/grpc/ > grpc-go/pull/993 > > Server side support is in review: https://github.com/ > grpc/grpc-go/pull/1119 > > On Thu, Jan 12, 2017 at 5:11 PM, 'Qi Zhao' via grpc.io < > [email protected]> wrote: > >> Yes, you are right. We need that heart-beat mechanism. >> >> On Thu, Jan 12, 2017 at 11:43 AM, Angel Luis Jimenez Martinez < >> [email protected]> wrote: >> >>> So if I understand correctly tcp user timeout applies to sent data that >>> has not been acknowledged. So in this case maybe it would not apply because >>> the server doesn't send any data to the dead client, am I right? >>> >>> >>> >>> >>> 2017-01-12 20:28 GMT+01:00 Qi Zhao <[email protected]>: >>> >>>> If the clients dies silently (without sending the TCP RST), the server >>>> side connection will stay until TCP user time out is triggered (order of >>>> tens of minutes depending on your kernel setup) in the current >>>> implementation unless you have a custom dialer to turn on TCP KeepAlive. We >>>> are working on a heart-beat mechanism to recycle the server connections in >>>> a timely fashion. It is WIP. >>>> >>>> On Tuesday, January 10, 2017 at 2:52:01 AM UTC-8, [email protected] >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I have implemented a Go gRPC server for an app backend and see that >>>>> client connections and the corresponding goroutines are still running even >>>>> if clients (Android apps) have died. I'm not using methods that stream >>>>> results from server to client or otherwise. >>>>> >>>>> Is this the expected behaviour? >>>>> >>>>> And if so, is there some kind of way on the Go server code to iterate >>>>> over client connections and then identify the old idle ones and close >>>>> them? >>>>> >>>>> Thanks! >>>>> >>>> >>> >>> >>> -- >>> Angel. >>> >> >> >> >> -- >> Thanks, >> -Qi >> >> -- >> 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/ms >> gid/grpc-io/CAFnDmdrwL6tnvPHojQfBt%2BXPiwnbNEHPXXgOcWapzvMsU >> 14FEw%40mail.gmail.com >> <https://groups.google.com/d/msgid/grpc-io/CAFnDmdrwL6tnvPHojQfBt%2BXPiwnbNEHPXXgOcWapzvMsU14FEw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "grpc.io" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/grpc-io/69k_6HKVai0/unsubscribe. > To unsubscribe from this group and all its topics, 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/CAPh%2BwgKkWh4kMJF8ZxLeeqW_5t6yKM6uDLiyo2zCzBuPzeonug% > 40mail.gmail.com > <https://groups.google.com/d/msgid/grpc-io/CAPh%2BwgKkWh4kMJF8ZxLeeqW_5t6yKM6uDLiyo2zCzBuPzeonug%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Angel. -- 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/CABRPPL%2BRMbqG5gsyrobiq5f7G3pPR9rDcS8-Qcy9RK0cfLBRkQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
