Details
-
Bug
-
Resolution: Fixed
-
Major
-
6.5.1, 6.6.0, Cheshire-Cat
-
Untriaged
-
1
-
Unknown
Description
As recommended here, it is advised to call close on gRPC.ClientConn whenever the application intends to not use it anymore ..
https://godoc.org/google.golang.org/grpc#Dial
To ensure resources are not leaked due to the stream returned, one of the following actions must be performed:
|
|
1. Call Close on the ClientConn. |
2. Cancel the context provided. |
3. Call RecvMsg until a non-nil error is returned. A protobuf-generated client-streaming RPC, for instance, might use the helper function CloseAndRecv (note that CloseSend does not Recv, therefore is not guaranteed to release all resources). |
4. Receive a non-nil, non-io.EOF error from Header or SendMsg. |
On Refresh(..), N1FTY sets up a new set of ClientConns' to FTS servers but does not close the dereferenced ClientConns. This will need fixing.
I used this command to track the number of open gRPC connections ..
netstat -an | grep ESTABLISHED | grep -w 9201 | wc -l |
With some code instrumenting by forcing indexer refreshes continuously - I'm able to see that the gRPC connections count (available from the above command) grow over time. The fix for this issue ensures that the number remains constant despite continuous refresh.
Attachments
Issue Links
- is duplicated by
-
MB-39803 [System Test] : Query logs have fatal errors - socket: too many open files
- Closed