FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

binder: Fail fast on transaction sequence gaps by NianJiuZst · Pull Request #13008 · grpc/grpc-java · GitHub

/ grpc-java Public

binder: Fail fast on transaction sequence gaps - #13008

Open
NianJiuZst wants to merge 1 commit into
grpc:masterfrom
NianJiuZst:codex/binder-fail-on-transaction-gap
Open

binder: Fail fast on transaction sequence gaps#13008
NianJiuZst wants to merge 1 commit into
grpc:masterfrom
NianJiuZst:codex/binder-fail-on-transaction-gap

Conversation

Copy link
Copy Markdown
Contributor

Binder one-way transactions are delivered in order, so sparse buffering cannot recover a silently dropped transaction. Detect unexpected sequence numbers and close the stream with UNAVAILABLE instead of waiting indefinitely. Simplify the now-sequential message queue and cover dropped messages and fragments in both directions.

Fixes #12747

Binder one-way transactions are delivered in order, so sparse buffering cannot recover a silently dropped transaction. Detect unexpected sequence numbers and close the stream with UNAVAILABLE instead of waiting indefinitely. Simplify the now-sequential message queue and cover dropped messages and fragments in both directions.

Fixes grpc#12747
kannanjgithub requested a review from jdcormie August 27, 2026 11:21

jdcormie left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Thanks for taking this on. This is a good start but I'd like to see Inbound simplified a lot more:

I don't think we need firstQueuedTransactionIndex or lookForCompleteMessage() anymore. We can simply assemble messages as soon as we see lastBlockOfMessage and store them in a new member named something like ArrayDeque<InputStream> availableMessages

I don't think we need suffixTransactionIndex either. When we see FLAG_SUFFIX we now know all previous transactions were received.

We don't need the TransactionData class anymore. Instead of queuedTransactionData, We can maintain an ArrayList<byte[]> partialMessageBlocks for fragments of large messages that need multiple txns. We can assemble fragments into messages as soon as the last fragment arrives. Assembly is so cheap it shouldn't matter which thread does it.

if (index != nextExpectedTransactionIndex) {
throw Status.UNAVAILABLE
.withDescription(
"Binder transaction sequence gap: expected "

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

gap isn't quite the right word. It could be a gap but it could also be a duplicate. How about "out-of-order transaction" ?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

binder: Inbound.java reassembly logic needlessly handles out-of-order transactions, fails to handle silently dropped ones.

2 participants


Back | FazBrowse Home | New Git URL