-
Notifications
You must be signed in to change notification settings - Fork 68
fix: thread memory leak in InProcessResolver #1678
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
base: main
Are you sure you want to change the base?
fix: thread memory leak in InProcessResolver #1678
Conversation
Summary of ChangesHello @paul-kraftlauget, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a critical memory leak in the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request fixes a thread leak in InProcessResolver by introducing a shutdown flag to allow the stateWatcher thread to terminate gracefully. The change is correct and addresses the issue.
My review includes two main points for improvement:
- In
InProcessResolver.java, I've suggested a more robust shutdown pattern using thread interruption. This would make the component's shutdown logic more self-contained and less reliant on the behavior of downstream components. - In
InProcessResolverTest.java, I've pointed out that the new test for the shutdown logic isn't fully representative of the production scenario, as it manually unblocks the thread instead of verifying that the shutdown process does so.
These suggestions aim to improve the robustness and test quality of the solution.
| final Thread stateWatcher = new Thread(() -> { | ||
| try { | ||
| while (true) { | ||
| while (!shutdown.get()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using a shutdown flag is a good step towards graceful shutdown. However, the thread will remain blocked on flagStore.getStateQueue().take() until an item is put on the queue. The current design relies on flagStore.shutdown() to eventually cause this.
A more robust and direct approach for shutting down a worker thread that blocks on a queue is to use thread interruption. This avoids relying on the indirect behavior of downstream components.
Consider this pattern:
- Store the
stateWatcherthread in an instance field. - In the
shutdown()method, callinterrupt()on the thread instance. - The
take()method will throwInterruptedException, which is already caught, and the thread will terminate.
This makes the shutdown logic of InProcessResolver self-contained and not dependent on the implementation details of FlagStore. It also handles cases where flagStore.shutdown() might fail or not behave as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this is true, what's been added here is an objective improvement.
@paul-kraftlauget ... up to you if you'd like to go further. I do think this comment is correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it was correct. And looking at the file sync implementation, there wouldn't be another event sent when shutdown, so the leak still would occur. I have pushed an update now. I hope it is ok.
...est/java/dev/openfeature/contrib/providers/flagd/resolver/process/InProcessResolverTest.java
Outdated
Show resolved
Hide resolved
|
@paul-kraftlauget Thanks a lot! can you fix the DCO failure? You can do a |
Signed-off-by: Paul Johe <[email protected]>
fdb1905 to
7142c1d
Compare
Signed-off-by: Paul Johe <[email protected]>
Signed-off-by: Paul Johe <[email protected]>
...rc/main/java/dev/openfeature/contrib/providers/flagd/resolver/process/InProcessResolver.java
Show resolved
Hide resolved
...est/java/dev/openfeature/contrib/providers/flagd/resolver/process/InProcessResolverTest.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Paul Johe <[email protected]>
Signed-off-by: Paul Johe <[email protected]>
This PR
Related Issues
Fixes #1677
How to test
Please see the unit test in this PR