fudianchn opened a new pull request, #16443: URL: https://github.com/apache/dubbo/pull/16443
AI disclosure: this change was prepared with AI coding agents, reviewed and revised line by line by me. ## What is the purpose of the change? Fixes #16427 (case 1). When a single gRPC message is larger than the HTTP/2 stream-level flow control window, the call deadlocks until it times out: the sender stops once the window is exhausted and waits for WINDOW_UPDATE, while the receiver buffers the partial message and waits for the remaining bytes. Two defects cause this: 1. `LengthFieldStreamingDecoder` only reported `bytesRead` after a full message was assembled (`processBody`), so bytes buffered inside an incomplete message were never returned to the peer. Now `decode()` reports the ingested bytes as soon as they are taken off the wire, and the per-message report in `processBody()` is dropped to avoid double counting. This matches the grpc-java deframer pattern already referenced in the code comment. 2. `consumeBytes()` (both `NettyH2StreamChannel` on the server side and `Http2TripleClientStream` on the client side) never flushed the WINDOW_UPDATE written by the flow controller: when consumption runs from an executor thread the frame reading loop does not flush it, and flushing the stream channel itself is a no-op for frames written directly to the connection. The frame observed in a frame log sat in the outbound buffer for 5 seconds until a timeout reset flushed it. Both sites now flush the parent channel when `consumeBytes` wrote an update. Verified both directions on a real localhost tri connection: with a 64 KiB initial stream window and the ~92 KiB message from the issue, the frame log shows the request and the response each delivered as 65535 + 29003 bytes with WINDOW_UPDATE flowing in between, instead of a deadlock until the 5s deadline. The second failure mode from the issue (window exceeded against a PHP gRPC peer) needs a peer that keeps sending beyond the advertised window and did not reproduce between two Netty endpoints, so it is not addressed here. Tests: `TripleFlowControlTest` (unary and server-stream against a real localhost endpoint, red before the change: DEADLINE_EXCEEDED after 5s, green after), `GrpcStreamingDecoderTest.reportsBytesReadForIncompleteMessage` (partial message reports its bytes, red before: expected 14 but was 0). `mvn -pl dubbo-remoting/dubbo-remoting-http12,dubbo-rpc/dubbo-rpc-triple -am test` passes. ## Checklist - [x] Make sure there is a [GitHub_issue](https://github.com/apache/dubbo/issues) field for the change. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Write necessary unit-test to verify your logic correction. If the new feature or significant change is committed, please remember to add sample in [dubbo samples](https://github.com/apache/dubbo-samples) project. - [x] Make sure gitHub actions can pass. [Why the workflow is failing and how to fix it?](../CONTRIBUTING.md) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
