-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Make AbstractSearchAsyncAction release resources earlier #124275
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
Make AbstractSearchAsyncAction release resources earlier #124275
Conversation
We can release resources earlier by releasing before responding to the listener (everything that needs retaining is retained via the search response already) as well as make the GCs life a little easier and get obvious correctness by using the listener that nulls out resources in a thread-safe manner intead of a non-thread-safe and mutable list shared across all kinds of places in the code.
|
Pinging @elastic/es-search-foundations (Team:Search Foundations) |
| if (doneFuture.isDone()) { | ||
| releasable.close(); | ||
| } else { | ||
| doneFuture.addListener(ActionListener.releasing((releasable))); |
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.
Minor: There is a pair of extra parenthesis around releasable.
| */ | ||
| public void addReleasable(Releasable releasable) { | ||
| releasables.add(releasable); | ||
| var doneFuture = this.doneFuture; |
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.
Should a check be added here to verify that the releasable is not null?
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.
No need to at this point I think, all the spots we're using this for are null safe. And we really shouldn't be adding more uses of this I think :) It's quite imprecise, many of the things we add here could probably be released earlier in their lifecycle. => no new nulls incoming either 🤞
drempapis
left a comment
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.
LGTM, thanks for sharing this
|
Thanks Dimitris! |
💚 Backport successful
|
…124800) We can release resources earlier by releasing before responding to the listener (everything that needs retaining is retained via the search response already) as well as make the GCs life a little easier and get obvious correctness by using the listener that nulls out resources in a thread-safe manner intead of a non-thread-safe and mutable list shared across all kinds of places in the code.
We can release resources earlier by releasing before responding to the listener (everything that needs retaining is retained via the search response already) as well as make the GCs life a little easier and get obvious correctness by using the listener that nulls out resources in a thread-safe manner instead of a non-thread-safe and mutable list shared across all kinds of places in the code (currently this pretty much just works out by accident because we only add resources when moving to new phases).
This also fixes a potential bug around adding a releasable resource after the listener has already failed.