[Subscription] Prevent event loss on poll payload overflow - #18471
Open
Caideyipi wants to merge 1 commit into
Open
[Subscription] Prevent event loss on poll payload overflow#18471Caideyipi wants to merge 1 commit into
Caideyipi wants to merge 1 commit into
Conversation
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.
Description
Root cause
The subscription brokers polled events before enforcing the cumulative response payload limit. When several individually valid events were selected for one response, the receiver could discover only during serialization that the cumulative payload exceeded the poll budget. It then nacked the event. After 10 identical retries, poison-message handling force-acked the event and permanently skipped its rows.
This matches regression test case 1392 exactly: two skipped writer_B events, each containing 10 rows, account for the 20-row gap between benchmark/IoTDB count (42,423,170) and consumed count (42,423,150).
The failing event itself was about 30 MB, not 68 MB. The reported 68,135,206 bytes was the cumulative response size after adding it. The effective server threshold was 60,397,977 bytes, which is 90% of the consumer's 64 MiB poll budget. Therefore the write path's payload limit was not violated; whether a writer_B event succeeded depended on how much data had already been selected for that poll response.
Fix
nack()or increasingnackCount.SubscriptionBrokerAgent.Verification
mvn spotless:apply -pl iotdb-core/datanodemvn -o test-compile -pl iotdb-core/datanode -DskipTestsConsensusSubscriptionBrokerPayloadLimitTest: 1 test, 0 failures/errorsSubscriptionBrokerAgentPayloadLimitTest: 1 test, 0 failures/errorsConsensusPrefetchingQueueTest: 27 tests, 0 failures/errorsgit diff --checkThis PR has:
Key changed/added classes
SubscriptionBrokerAgentConsensusSubscriptionBrokerSubscriptionBrokerConsensusPrefetchingQueueSubscriptionPrefetchingQueueSubscriptionReceiverV1