imzs opened a new issue, #10615:
URL: https://github.com/apache/rocketmq/issues/10615

   ### 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/discussions).
   
   - [x] I have searched the [GitHub 
Issues](https://github.com/apache/rocketmq/issues) and [GitHub 
Discussions](https://github.com/apache/rocketmq/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.
   
   
   ### 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 on 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.
   
   However, CombineConsumeQueueStore also instantiates an inner 
RocksDBConsumeQueueStore (when combineCQLoadingCQTypes contains 
DEFAULT_ROCKSDB). Because the flag lives on 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, on the other hand, 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 avoidable consume latency.
   
   ### Steps to Reproduce
   
   .
   
   ### What Did You Expect to See?
   
   .
   
   ### What Did You See Instead?
   
   .
   
   ### Additional Context
   
   _No response_


-- 
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]

Reply via email to