odbozhou commented on pull request #3444: URL: https://github.com/apache/rocketmq/pull/3444#issuecomment-957136997
> > In order to prevent the message from being lost. Revive topic queue Offset update needs to pass ck msg. Revive topic contains both ck msg and ack msg. If the offset is updated directly by the number of Revive topic queue messages, there is a possibility of message loss. For example, some ck msgs are not confirmed by ack msg. , And without sending the retry topic, the offset of the receive topic is updated directly. There is a possibility of repetition of ack msg due to the network or other reasons. The message corresponding to ack has been acked, and ack will be consumed repeatedly, but it has no effect. These ack msg will not be consumed repeatedly when the new ck msg is updated. NS > > @odbozhou Thanks for the explanation, but I have two questions: > > * The offset was updated after putting messages into retry topic. Is it possible to fail to put msgs? > * Even if the above example happens, updating the offset by the ck msgs and updating it by the number of Revive topic queue messages are the same, because the ck msgs will be consumed only once. So I think updating the consume offset by the number of msgs directly will be better.  - The ck message is not necessarily consumed only once. As shown in the figure, if break at this step, some ck has not been confirmed, and no retry topic has been sent. However, the consumption location of the receive topic queue is updated by the number of msgs. The unacknowledged ck message may lose the message, which does not meet the semantics of at least once. - The msg in the receive topic has both ck and ack。 and it cannot only mean the number of ck. -- 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]
