Let me clarify one point - I was expecting the client to close the connection after the GOAWAY. Is there a reason to leave the connection open after that point?
Art On Friday, April 28, 2023 at 8:42:58 AM UTC-7 Arthur Naseef wrote: > Thank you for the response. we are aware of the semantics, and they do as > advertised - the Channel goes into IDLE on the GOAWAY. However, the > CONNECTION itself lingers indefinitely. So every time we get a GOAWAY from > the server, we leak a connection - until that connection is closed by the > server itself. I was expecting the connection to close after receiving the > GOAWAY. > > We call getState with true as a means of ensuring the client does its best > to keep the connection to the server. The README.md in the POC project > explain why. In short - the server pushes messages to the client (via GRPC > stream), the server cannot initiate the connection to the client, and the > client does not know when the server will send messages. So, the client > does it's best to keep the connection to the server active at all times. > > Art > > On Friday, April 28, 2023 at 2:13:58 AM UTC-7 [email protected] wrote: > >> Take a look at >> https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md >> >> - it says "...channels that receive a GOAWAY when there are no active or >> pending RPCs should also switch to IDLE..." >> >> Also according to >> https://github.com/grpc/grpc-java/blob/master/api/src/main/java/io/grpc/ManagedChannel.java#L78 >> >> if you call `getState` with `true` then "the channel will try to make a >> connection if it is currently IDLE ". And that might explain why your >> `getState` call itself causes a new connection to be created. I haven't >> looked at your code in detail but do you need to call `getState` with >> `true`? Can you try with `false` ? >> >> >> >> >> >> On Friday, April 28, 2023 at 3:13:37 AM UTC+5:30 Arthur Naseef wrote: >> >>> I am running into an issue with the GRPC Java client in which the client >>> leaks connections over time. Reading through the grpc-java code, >>> debugging, and instrumenting has led my the following question: >>> >>> - Does the netty client code ever close the connection except when >>> it sees the socket close intiaited externally (i.e. by the O/S or the >>> server)? >>> >>> Here is a small project that (1) contains a description of the problem >>> and some of the history related to it, and (2) can be used to reproduce the >>> connection leak. >>> >>> https://github.com/artnaseef/opennms-poc-hs1384 >>> >>> In brief, we see the following: >>> >>> - The NGINX ingress times out a request >>> - The NGINX ingress sends a GOAWAY packet to the client. >>> - The client channel transitions to IDLE but does not close the >>> connection. >>> - The client creates a new connection for the channel, which >>> transitions to CONNECTING and then READY >>> - The list of transports for the channel holds the leaked connections >>> >>> Note that switching to the OK HTTP implementation appears to improve the >>> results with the test tool, but our main application still observes leaked >>> connections when running with OK HTTP. >>> >>> Any help is appreciated. I can certainly share more details as needed. >>> >>> Art >>> >>> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/d9a8271c-ee25-4b76-a802-546c69e4cedbn%40googlegroups.com.
