Repository navigation
Read every received entry through the stream: an entry ending at the end of the sender's buffer is read through to its final frame - #310
Merged
Conversation
…ugh to its final frame
…t's buffer, each followed by another
sakno
reviewed
Nov 2, 2026
…through the stream Its fast path saved a copy only when an entry's payload came whole in a final frame that fit in the buffer, and with the write-ahead log copying into its own pages it saves nothing. It was also where an entry ending at the end of the sender's buffer went wrong, its empty final frame left to be read as the next entry's metadata.
galvesribeiro
changed the title
Member
Author
|
/azp run |
|
Commenter does not have sufficient privileges for PR 310 in repo dotnet/dotNext |
Member
Author
|
Hello @sakno! Can we get a release with this? Thanks! |
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
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.
Fixes #308.
ProtocolStream.TryReadFrameDatatook an entry's payload in one go when its frame held it whole, even from a non-final frame. A payload that ends where the sender's buffer ended arrives in a full, non-final frame followed by an empty final frame, whose header was then left to be read as the next entry's metadata.The method is removed: every received entry is read through the stream, which reads the final frame too. Its fast path saved a copy only when a payload came whole in one frame within the buffer, and with the write-ahead log copying into its own pages it saves nothing.
Test:
TcpTransportTests.SendingLogEntriesAcrossFrames(the sharedTransportTestSuite.SendingLogEntriesAcrossFramesTest) sends two entries for every first-entry size from 1 to 1000 bytes with a 400-byte block and checks both arrive as sent. Without the fix it fails withMemberUnavailableExceptionat the size ending at the buffer's end.