wolfstudy commented on code in PR #15628:
URL: https://github.com/apache/pulsar/pull/15628#discussion_r1003945282
##########
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:
Yes @Jason918 , if the user uses a delayed message here and sets a TTL
policy at the same time, the situation you described may exist. But compared to
the situation where the TTL policy and delayed messages conflict with each
other and cause message loss, I think this cost is acceptable. Or is there any
other better way to avoid message loss in this scenario?
--
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]
