You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rocketmq.apache.org by GitBox <gi...@apache.org> on 2021/11/18 08:58:54 UTC
[GitHub] [rocketmq] cserwen opened a new issue #3507: [POP] The endTime for popReviveService is bigger than actual
cserwen opened a new issue #3507:
URL: https://github.com/apache/rocketmq/issues/3507
**BUG REPORT**
1. Please describe the issue you observed:
- What did you do (The steps to reproduce)?
Produce msgs and consume by pop.
- What did you expect to see?
Message should be consumed successfully.
- What did you see instead?
Some messages entered the retry queue
2. Please tell us about your environment:
Linux
3. Other information (e.g. detailed explanation, logs, related issues, suggestions how to fix, etc):
The reviveThread will consume msg in `reviveTopic` and cal a endTime for a batch of msgs
```java
long deliverTime = MsgUtil.getMessageDeliverTime(this.brokerController, messageExt);
if (deliverTime > endTime) {
endTime = deliverTime;
}
```
This value of endTime is bigger than actual because the storeTime of ck or ack msgs is its delivery time. There is no need to calculate this value again.
When this value is bigger than actual. The below codes will think some ck msgs should be revived.
```java
if (consumeReviveObj.endTime - popCheckPoint.getReviveTime() <= (PopAckConstants.ackTimeInterval + PopAckConstants.SECOND)) {
break;
}
```
The picture below will be clearer：
The orange message should really be processed, but in fact the blue message has also been processed.
--
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: dev-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] cserwen commented on issue #3507: [POP] The endTime for popReviveService is bigger than actual
Posted by GitBox <gi...@apache.org>.
cserwen commented on issue #3507:
URL: https://github.com/apache/rocketmq/issues/3507#issuecomment-1036003012
> IMO, using deliverTime as endTime has no effect to pop function, the blue message that is still in SCHEDULE_XXX topic will be delivered to retry topic in advance. The key problem is using deliverTime or storeTime as the end time point using for judging timeout.
@lizhiboo I think this works, if this endtime is true, the judgment on recovery here will take effect,
https://github.com/apache/rocketmq/blob/631405e2fba8849f9bce5e275825aa16944b8097/broker/src/main/java/org/apache/rocketmq/broker/processor/PopReviveService.java#L344
--
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: dev-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [rocketmq] lizhiboo commented on issue #3507: [POP] The endTime for popReviveService is bigger than actual
Posted by GitBox <gi...@apache.org>.
lizhiboo commented on issue #3507:
URL: https://github.com/apache/rocketmq/issues/3507#issuecomment-1035747521
IMO, using deliverTime as endTime has no effect to pop function, the blue message that is still in SCHEDULE_XXX topic will be delivered to retry topic in advance. The key problem is using deliverTime or storeTime as the end time point using for judging timeout.
--
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: dev-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org