-
Notifications
You must be signed in to change notification settings - Fork 299
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add missing Dispose() calls #1552
Add missing Dispose() calls #1552
Conversation
Welcome @brianpursley! |
Hmm, i think I can't do this:
... because this is not awaited ...
So the
|
14550c1
to
71a16b5
Compare
OK, removed the |
Good catch /LGTM |
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #1552 +/- ##
=========================================
Coverage ? 61.50%
=========================================
Files ? 103
Lines ? 3068
Branches ? 639
=========================================
Hits ? 1887
Misses ? 1181
Partials ? 0 ☔ View full report in Codecov by Sentry. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: brianpursley, tg123 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
While not recommended, if you repeatedly create a Kubernetes client inside of a loop, there appears to be a memory leak, even if you dispose it.
This PR adds the following to fix this:
.Dispose()
forFirstMessageHandler
.Dispose()
forHttpClientHandler
Dispose()
methodAddsUsing
forhttpRequest
(while unrelated to the Kubernetes client lifecycle, I believe this should also be disposed)Possible fix for #1539 (I suspect that issue is not related only to aot).
Test Results
I tested this using the following console program and running in Rider using memory profiling (sampled allocations):
Before the fix
Memory increases slowly, eventually reaching ~163MB by the end of the program:
After the fix
Memory holds stead around ~123MB: