leizhiyuan opened a new issue, #1424: URL: https://github.com/apache/rocketmq-clients/issues/1424
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq-clients/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq-clients/issues) and [GitHub Discussions](https://github.com/apache/rocketmq-clients/discussions) of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Programming Language of the Client Rust ### Runtime Platform Environment macOS 27 (arm64) ### RocketMQ Version of the Client/Server Client: Rust `rocketmq` 5.0.0, master `a3d1de8b` with #1404 (`b5cb4940`, still open) merged on top Server: a managed RocketMQ 5.x service (Tencent Cloud TDMQ for RocketMQ 5), gRPC proxy endpoint ### Run or Compiler Version rustc 1.98.0 ### Describe the Bug This bug is in code added by #1404, which is not merged yet. When the server pushes a `long_polling_timeout` in `Settings`, `PushConsumer` (and so `LitePushConsumer`) sends the server value in `ReceiveMessageRequest`, but the client-side gRPC deadline stays at the configured value. When the server does not answer at its own timeout, the receive request hangs until the configured deadline. **Scenario.** The server pushes `long_polling_timeout = 20s`. The client keeps the default of 40 s, with `timeout` 3 s. Most receive requests return after 20 s. Some of them get no answer at 20 s and only end at 43 s with `status: Cancelled, message: "Timeout expired"`. This also adds to `shutdown()`, which waits for in-flight receive requests (#1422). In 2 out of 6 end-to-end runs, shutdown took about 28 s instead of about 5 s. **Root cause.** - #1404 added `SharedLongPollingTimeout`. The session computes the receive deadline from it as `long_polling_timeout + timeout` (`Session::receive_deadline`). `SimpleConsumer` writes the server value into it. - #1404 also added `PushConsumer::apply_settings`. That only writes the server value into `PushConsumerOption`, which is what the request carries. It does not write the shared value, so the deadline still uses the configured 40 s. **Java behavior.** `ConsumerImpl#receiveMessage` uses the same `awaitDuration` (the server's `longPollingTimeout` from `PushSubscriptionSettings#sync`) for the request and for the client deadline, `awaitDuration + requestTimeout`. Here that is 20 s + 3 s = 23 s. ### Steps to Reproduce 1. Use a server that pushes a subscription `long_polling_timeout` shorter than the client's `ClientOption::long_polling_timeout` (default 40 s). 2. Start a `PushConsumer` / `LitePushConsumer` and let it poll an idle queue. 3. Look at how long receive requests take before they end. ### What Did You Expect to See? Receive requests end at most at server `long_polling_timeout + timeout` (23 s here), as with the Java client. ### What Did You See Instead? Some receive requests end only at `40 s + 3 s` with `Timeout expired`. ### Additional Context The fix is based on #1404 and its PR should be merged after it. --- Tracked in #1412. -- 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]
