Aaron-He commented on pull request #2290: URL: https://github.com/apache/rocketmq/pull/2290#issuecomment-694729884
> The approach is obvious and vivid, here are some suggestions(maybe I don't have a thorough graspt of code): > > 1. Besides DelayMsgCheckPoint file is persisted on master node, the checkpoint should also be synchronized to slave node periodly; otherewise, if master node crashes down and fails to restart, slave node does not know the timestamp the message can be delivered from; > 2. In method putKey() of file DelayMsgIndexFile.java, if the method is used in multi threads, we will need to lock before operating the index file; otherwise, we might not need to release the file lock since we never use it; > 3. For the message delivered, we'd better keep its physical commitlog offset to a log let's call it deliveryLog, > if master node restarts, we need to find out all the the undelivered messages between deliveryLog and index file, it can try to reduce the number of duplicated messages on the server side. > Whether or not to sync the deliveryLog to slave node? Maybe we need to discuss it later. > 4. If a large mount of delay messages fall into lots of commitlog files randomly, the speed of delivering delay messages will be slow because of random reading. From our internal tests, the speed is about 200-300 tps on normal disk(15K Rounds Per Minute). Shall we need to limit produce rate? > > Let's work together to build open source community better. 1. Good suggestion 2. putKey() is used by reputService, which is single thread. yeah, we can remove the release code block. 3. Good suggestion. As current implementation, user identifies duplicate messages. 4. It may not work to limit produce rate, because the delayMsgs delivery is up to its startDeliverTime. We can use more memory to make performance better. There may be other better solutions. Let's work together to build open source community better. ^_^ ---------------------------------------------------------------- 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]
