rocketmq
rocketmq copied to clipboard
Why is the consume offset become less when the timestamp set to “now”?(MQAdmin)
when I'm trying to use resetOffsetByTime command from mqadmin,if I set to now,seems like the rollback offsets returned by the console will always less then the broker offset,why?
sos
First of all, 4.3.0 uses this command resetOffsetByTime, which is indeed the offset of the rollback. And the actual command in the above picture is this resetOffsetByTimeOld, this command is not supported in 4.3.0, and the parameters of the above picture cannot be run with this command, so the author of the above picture changed the source code and ran out.
The code will update the offset through comparison. In fact, there is no problem. If there is any ambiguity about this, you can use the resetOffsetByTime command instead of the resetOffsetByTimeOld.
First of all, 4.3.0 uses this command resetOffsetByTime, which is indeed the offset of the rollback. And the actual command in the above picture is this resetOffsetByTimeOld, this command is not supported in 4.3.0, and the parameters of the above picture cannot be run with this command, so the author of the above picture changed the source code and ran out.
Hi In fact I don't quite understand what you mean, but I found that last year, someone has already noticed this bug, and if you look carefully at the source code will know that either resetOffsetByTime or resetOffsetByTimeOld, the core method to get the specified timestamp offset is always method getOffsetInQueueByTime, and this method I debugged, the timestampOffet will always be smaller than the actual correct consumption offset of 1 unit, so I think it's nothing to do with the version or the commands we use.
https://github.com/apache/rocketmq/issues/2661 you can see this issue
#2661 you can see this issue
Thanks for the heads-up. But does this meet the exact business need really? Why not just set the timestamp to -1 when users need to reset to "now"?
This issue is stale because it has been open for 365 days with no activity. It will be closed in 3 days if no further activity occurs.
This issue was closed because it has been inactive for 3 days since being marked as stale.