qianye1001 commented on PR #10907: URL: https://github.com/apache/rocketmq/pull/10907#issuecomment-5252009953
CI follow-up The original JDK 8 integration failure was unrelated to the MQClientManager production change, but it exposed two real timing assumptions in existing integration tests. Commit `52184f84f1` stabilizes them without weakening their assertions: - `QueryMsgByKeyIT` now waits for the asynchronously built message index and retries only the expected `MQClientException` that reports no indexed message yet. - `BatchAckIT` now waits until all sent messages are visible in the consume queues before the first orderly POP. This prevents a partially dispatched queue from being order-locked after returning only part of the batch. Its POP assertion also allows multiple 3-second long-poll attempts on a busy runner. A later macOS/JDK 8 Build run exposed a separate flaky `ServiceThreadTest`: it classified any wakeup taking 18-20 ms as lost, so one OS scheduling delay failed the test. Commit `1385ac7975` replaces that performance threshold with a barrier-based protocol. One waiter and four wakers coordinate every iteration; all 1,000 notified waits must complete, while an actually lost wakeup breaks the 20-second coordination bound. Validation on the final head `1385ac7975`: - Build with Maven / macOS JDK 8: passed in 36m14s - Build with Maven / Ubuntu JDK 8: passed in 40m35s - Build with Maven / Windows JDK 8: passed in 44m27s - Integration Tests / Ubuntu JDK 8: passed in 25m33s - Coverage, CodeQL, Bazel, License, and Misspell: passed Local Oracle JDK 8 validation also passed `MQClientManagerTest` (7/7), `QueryMsgByKeyIT` (4/4), the formerly failing orderly `BatchAckIT` path (1/1), and `ServiceThreadTest` twice (7/7 each run). -- 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]
