wolfstudy commented on code in PR #15628:
URL: https://github.com/apache/pulsar/pull/15628#discussion_r1004328608
##########
pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentMessageExpiryMonitor.java:
##########
@@ -77,8 +77,10 @@ public boolean expireMessages(int messageTTLInSeconds) {
cursor.asyncFindNewestMatching(ManagedCursor.FindPositionConstraint.SearchActiveEntries,
entry -> {
try {
- long entryTimestamp =
Commands.getEntryTimestamp(entry.getDataBuffer());
- return MessageImpl.isEntryExpired(messageTTLInSeconds,
entryTimestamp);
+ // When the time of the delayed message is greater than
the time specified by TTL, we should
+ // give up checking the TTL of the current delayed
message, because the time of the delayed
+ // message has not yet arrived, we cannot delete these
messages.
+ return MessageImpl.isEntryExpired(messageTTLInSeconds,
entry.getDataBuffer());
Review Comment:
I don't think so. Why do users need to perceive this matter? TTL and delayed
messages are two completely independent things.
--
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]
