-
Notifications
You must be signed in to change notification settings - Fork 903
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* [Java] Update active loss gap upon length change. Gap length can increase when heartbeats advance the high-water mark position, or it can decrease if messages arrive out of order. In both cases we want to adjust the NAK range of the receiver. * [Java] Update offset masking code to cast the result and not the position. * [Java] Read high-water mark position after computing the rebuild position to ensure the widest possible loss detection scan window. Loss detection code is concurrent to the application threads that are consuming from the image but also to the receiver thread that inserts new packets into the image and advances the high-water mark position counter. Reading that counter last ensures that we take into account all inserted packets up to this point. * [Java] Simplify `sendData` path by assuming that the window is almost never zero. Also do not track padding bytes as the "sent bytes". * [Java] Take into account a trailing padding frame when adjusting high-water mark on the receiver. A single network packet might contain multiple frames (up to an MTU). When such packet contains only `HDR_TYPE_DATA` then packet length will correspond to the combined lengths of the frames it contains. However, if there is a trailing `HDR_TYPE_PAD` packet then the packet length will not be equal to the sum of the frame sizes. For example, given a packet containing two 80 byte messages (whose aligned length is 128 bytes each) and a padding for 224 bytes. The length of the packet will be 288 bytes (256 + 32) but the "frame size" will be 512 bytes (256 + 256). * [Java] Simplify term gap scanning logic by removing `ALIGNED_HEADER_LENGTH` and streamlining non-zero frame lookup. * [Java] Add a test for `rcv-hwm` position update when a packet contains trailing padding frame + rename method that computes the target position offset. * [Java] Increment `snd-bpe` if window is zero or too small to fit a frame of data. * [Java] Do not take into account actual padding size as the `rcv-hwm` will advance on next heartbeat/data frame anyway. * Revert "[Java] Increment `snd-bpe` if window is zero or too small to fit a frame of data." This reverts commit 9b8229c. * Revert "[Java] Simplify `sendData` path by assuming that the window is almost never zero. Also do not track padding bytes as the "sent bytes"." This reverts commit 411f102. * Revert "[Java] Read high-water mark position after computing the rebuild position to ensure the widest possible loss detection scan window." This reverts commit 60e6047. * [C] Simplify term gap scanning logic by removing `ALIGNED_HEADER_LENGTH` and streamlining non-zero frame lookup. * [C] Update active loss gap upon length change. Gap length can increase when heartbeats advance the high-water mark position, or it can decrease if messages arrive out of order. In both cases we want to adjust the NAK range of the receiver.
- Loading branch information
1 parent
05e80f1
commit 5db3ae0
Showing
9 changed files
with
598 additions
and
112 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.