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/eb3948d7-a5b3-477d-ae28-f2455c80980dn%40googlegroups.com.

Reply via email to