Before Creating the Bug Report
Runtime platform environment
.
RocketMQ version
.
JDK Version
.
Describe the Bug
ReputMessageService#doReput() decides whether to notify long-polling consumers right after dispatching a message to the consume queue.
Previously this decision was driven by a boolean field (notifyMessageArriveInBatch) in DefaultMessageStore, which was flipped to true as a side effect inside the RocksDBConsumeQueueStore. The rationale is correct for a pure RocksDB CQ: the RocksDB consume queue is built asynchronously by RocksGroupCommitService, which performs the notification itself once the CQ is committed, so reput-time notification would wake consumers before the message is visible, so we must skip it.
However, CombineConsumeQueueStore also instantiates an inner RocksDBConsumeQueueStore (when combineCQLoadingCQTypes contains DEFAULT_ROCKSDB). Because the flag lives in the shared DefaultMessageStore, this constructor disables reput-time notification for the entire store — even when selective double-write (rocksdbCQSelectiveDoubleWriteEnable=true) is enabled.
Under selective double-write, RocksDB CQ is only double-written for a subset of topics. As a result: Topics that are not double-written to RocksDB never go through the RocksGroupCommitService notification path. These consumers are therefore only woken up by the long-polling timeout, adding consume latency.
Steps to Reproduce
.
What Did You Expect to See?
.
What Did You See Instead?
.
Additional Context
No response
Before Creating the Bug Report
I found a bug, not just asking a question, which should be created in GitHub Discussions.
I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.
I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.
Runtime platform environment
.
RocketMQ version
.
JDK Version
.
Describe the Bug
ReputMessageService#doReput() decides whether to notify long-polling consumers right after dispatching a message to the consume queue.
Previously this decision was driven by a boolean field (notifyMessageArriveInBatch) in DefaultMessageStore, which was flipped to true as a side effect inside the RocksDBConsumeQueueStore. The rationale is correct for a pure RocksDB CQ: the RocksDB consume queue is built asynchronously by RocksGroupCommitService, which performs the notification itself once the CQ is committed, so reput-time notification would wake consumers before the message is visible, so we must skip it.
However, CombineConsumeQueueStore also instantiates an inner RocksDBConsumeQueueStore (when combineCQLoadingCQTypes contains DEFAULT_ROCKSDB). Because the flag lives in the shared DefaultMessageStore, this constructor disables reput-time notification for the entire store — even when selective double-write (rocksdbCQSelectiveDoubleWriteEnable=true) is enabled.
Under selective double-write, RocksDB CQ is only double-written for a subset of topics. As a result: Topics that are not double-written to RocksDB never go through the RocksGroupCommitService notification path. These consumers are therefore only woken up by the long-polling timeout, adding consume latency.
Steps to Reproduce
.
What Did You Expect to See?
.
What Did You See Instead?
.
Additional Context
No response