grpc-js: Stop leaking freed message buffer placeholder objects#2372
Merged
murgatroid99 merged 1 commit intogrpc:@grpc/grpc-js@1.8.xfrom Feb 24, 2023
Merged
Conversation
gnossen
approved these changes
Feb 24, 2023
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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 fixes #2371. Currently, in a retrying call, when a message that has been sent is no longer needed, its entry in the message buffer is replaced with a placeholder entry with
entryType="FREED". This frees up the memory of the actual message contents, but in a long-running stream, the placeholder entries themselves can pile up and start to use a significant amount of memory.With this change, the message buffer only contains the range of messages that still need to be sent, and the new
writeBufferOffsetfield indicates the offset the buffer has from the beginning of the message stream. The code still tracks message indices relative to the start of the message stream, because that can always just be incremented without any concern for the current state of the buffer.