saharaheart commented on issue #2830: URL: https://github.com/apache/rocketmq/issues/2830#issuecomment-826005873
Is there any code that indicates the SYNC_MASTER and SYNC_FLUSH mechanism? I rechecked that the reputMessageService(org.apache.rocketmq.store.DefaultMessageStore.ReputMessageService) relies on the commitedOffset to transfer commitlog to consumerQueue. It could be traced from ReputMessageService#doReput(). The SelectMappedBufferResult result = DefaultMessageStore.this.commitLog.getData(reputFromOffset); in doReput() finally use commitedOffset as the bound to do the reput. However, The commitedOffset is updated by the CommitRealTimeService (org.apache.rocketmq.store.CommitLog.CommitRealTimeService). This service will just update the commitedOffset periodly, which does not consider if the data is actually flushed to the disk. The flush operation is actually happened in another thread. There is no syncronization between them. So in this case, even in the SYNC_MASTER and SYNC_FLUSH settings, there is no gurantee to make the reputService waitfor the disk flush and slave replication. I wonder if I miss something or this is what actually what rocketmq is designed. -- 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. For queries about this service, please contact Infrastructure at: [email protected]
