leizhiyuan opened a new issue, #1450: URL: https://github.com/apache/rocketmq-clients/issues/1450
### 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 Linux 6.6 x86_64, 32 cores ### RocketMQ Version of the Client/Server Client: Rust `rocketmq` 5.0.0, master `e90ece7a` Server: a mock proxy that speaks the real gRPC protocol over TCP (see the benchmark in the tracking issue); the defects are also visible by reading the code against the Java client. ### Run or Compiler Version rustc 1.97.1 (also checked with 1.74.0, the MSRV) ### Describe the Bug On rebalance, `process_assignments` first shuts down the actors of the queues that are no longer assigned and waits for them ([push_consumer.rs#L488](https://github.com/apache/rocketmq-clients/blob/e90ece7a/rust/src/push_consumer.rs#L488)); only then does it start the newly assigned queues ([#L511](https://github.com/apache/rocketmq-clients/blob/e90ece7a/rust/src/push_consumer.rs#L511)). Shutting an actor down waits for its in-flight receive, i.e. up to `long_polling_timeout + timeout` (43 s by default). During that time the new queues are not consumed, and the telemetry loop that runs the scan is blocked too, so server-pushed settings are not applied. Java only marks the dropped process queue as dropped (`PushConsumerImpl#dropProcessQueue`, `ProcessQueueImpl#drop`); the in-flight request finishes in the background and no further receive is sent. New process queues fetch immediately (`fetchMessageImmediately`). Waiting for in-flight receives only happens on consumer shutdown (`waitingReceiveRequestFinished`). ### Steps to Reproduce Queue 0 is assigned and empty (its receive is held for the long polling timeout, 10 s here); the assignment then moves to queue 1. ### What Did You Expect to See? Queue 1 is polled right after it is assigned. ### What Did You See Instead? First receive on queue 1 after it was assigned: 10,040 ms on `master`, 1 ms with the fix. ### Additional Context Part of #1445. -- 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]
