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.
The scope of TTL is an entire namespace (at least before version 2.9.0,
Topic Policies was not very stable). When the TTL policy is set on the
namespace side, do we require users to delay messages longer than TTL? time? I
feel this is unacceptable for users.
--
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]
