-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fix potential resource leak in AvoidStandbyModeService #3909
Fix potential resource leak in AvoidStandbyModeService #3909
Conversation
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.
ACK - Tested it locally on Regtest. Toggling the avoid standy by feature (I can hear the sound behaving as before) everything works as before from a user perspective. Thanks for looking into this 👍
I just don't merge it immediately as I want to wait until #3889 gets merged so @cbeams doesn't need to do any unnecessary merges.
@stejbac Could you please resolve the conflict, caused by the recent gRPC PR merge? |
Afterwards I'm happy to merge your PR |
Replace tail recursion of the play() method with an ordinary loop, to prevent a new open JAR resource InputStream + sound file OutputStream (which were created every 4 minute playback) from accumulating on the stack, closing them inside the loop instead. (This also prevents eventual stack overflow.) Also tidy up FileUtil.resourceToFile and put the JAR URL InputStream in a try-with-resources block, to ensure that it doesn't leak either.
d6d23cc
to
a073dbf
Compare
I've rebased onto master. (The conflict in |
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.
ACK - #3909 (review)
Replace tail recursion of the
AvoidStandbyModeService.play
method with an ordinary loop, to prevent a new open JAR resource InputStream + sound file OutputStream (which were created every 4 minute playback) from accumulating on the stack, closing them inside the loop instead. (This also prevents eventual stack overflow.)Also tidy up
FileUtil.resourceToFile
and put the JAR URL InputStream in a try-with-resources block, to ensure that it doesn't leak either.--
Running lsof does reveal an accumulation of file handles without this fix, although not as many as one would expect from a new stream being opened every 4 minutes - perhaps they were being closed somehow in a finaliser?
Also, JProfiler revealed an accumulation of
ZipInputStream
objects from loading the .aiff JAR resource.