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/537c3dff-58f7-46f5-ab32-f8e8e1324bean%40googlegroups.com.
