This repository has been archived by the owner on Mar 1, 2024. It is now read-only.
Fix memory leak for worker fallbehind timers #35
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.
This is a quick fix for a memory leak that I noticed by comparing heapdumps. If you think a different fix is more appropriate, please feel free to implement something else.
Anyway, when a worker dies, the worker object in the master process never gets garbage collected because the fall-behind timer object still holds a reference to it. Since the callback to setTimeout calls measureFallBehind() and sets up a new timeout again, the timer is never cleaned up either.
This patch modifies the callback to setTimeout so that it only calls that.measureFallBehind() if the worker isn't dead, preventing the timer from being set up again and allowing the Timer and Worker objects to be garbage collected.