This repository has been archived by the owner on Aug 31, 2022. It is now read-only.
[Tentative for memleak][No merge]: Force OS mem release #95
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First cut; Fixed leak in my repro;
[ Done on commit that is in 202012 -- 1c3f75e ]
./gnmi_cli --client_types=gnmi -alocalhost:50051 -q COUNTERS -logtostderr -insecure -timestamp on -t COUNTERS_DB -qt s -streaming_type ON_CHANGE
TODO: Try it with repro from Pradnya.
Changes:
Some Analysis:
a) No leak of subscribe clients
Matched count of initial poll queries with client shutdown message
b) No leak of Go routines:
Looked at the count from logs. It increased during my repro run and went back to original + 1 after I stopped the client.
Not sure about that +1
c) Invalid connections go away quick
The subscribe RPC call create a gnmi_client/client_subscribe and call Run on it
New gnmi-client from client_subscribe wait for subscribe request
Creates DB client, if target is DB
DB client, does fetch on table keys and this fails
DB client terminates right there
gnmi-client exits right away