qianye1001 opened a new pull request, #1322: URL: https://github.com/apache/rocketmq-clients/pull/1322
### Which Issue(s) This PR Fixes Fixes #1321 ### Brief Description The Java push consumer previously generated a new receive attempt ID after every successful response, including an empty response, and preserved the current attempt ID only when a receive RPC failed with `DEADLINE_EXCEEDED`. This change keeps the request attempt ID across: - any failed receive RPC, regardless of the gRPC status; and - a successful receive response that contains no messages. A new attempt ID is generated only after the raw receive response contains at least one message. The check intentionally happens before message-interceptor filtering because the server has completed delivery even if the interceptor removes every returned message. This allows a retry to recover a server-side receive result after a response is lost or one HTTP/2 receive stream is reset, which is especially important when the previous attempt owns FIFO order state. The change is limited to `PushConsumer`. `SimpleConsumer` does not populate an attempt ID in its receive request, so its behavior is unchanged. ACK, redelivery, and delivery-attempt semantics are not changed, and this does not introduce exactly-once delivery. ### How Did You Test This Change? Ran the Java test reactor on JDK 11, including compilation, Checkstyle, SpotBugs, and the updated integration test: ```shell mvn -pl test -am -Dtest=AttemptIdIntegrationTest -Dsurefire.failIfNoSpecifiedTests=false test ``` Result: `BUILD SUCCESS`; `AttemptIdIntegrationTest` passed 1/1. The integration test verifies one consecutive sequence of a deadline, a non-deadline transport failure, an empty response, and a response containing a message. The first four requests use the same attempt ID, and the request after the message response uses a new ID. Also validated on Kubernetes with newly created NORMAL/FIFO topics and consumer groups and an external h2c proxy that resets only one `ReceiveMessage` HTTP/2 stream while preserving the TCP connection and unrelated streams: - Old client: after `CANCELLED: RST_STREAM`, the next receive used a different attempt ID; in the reproduced FIFO lock case no callback occurred within 180 seconds. - Modified client: the retry reused the same attempt ID, received the original FIFO message in about one second with `deliveryAttempt=1`, and acknowledged it successfully. - A response blackhole ending in `DEADLINE_EXCEEDED` was used as a control; the old client already retained the attempt ID for that status. -- 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]
