chia7712 commented on code in PR #22873:
URL: https://github.com/apache/kafka/pull/22873#discussion_r4100354665


##########
storage/src/main/java/org/apache/kafka/storage/internals/log/UnifiedLog.java:
##########
@@ -2000,39 +2000,34 @@ public interface DeletionCondition {
     }
 
     private int deleteRetentionMsBreachedSegments() throws IOException {
-        long retentionMs = UnifiedLog.localRetentionMs(config(), 
remoteLogEnabledAndRemoteCopyEnabled());
+        boolean remoteLogEnabledAndRemoteCopyEnabled = 
remoteLogEnabledAndRemoteCopyEnabled();
+        long retentionMs = UnifiedLog.localRetentionMs(config(), 
remoteLogEnabledAndRemoteCopyEnabled);
         if (retentionMs < 0) return 0;
         long startMs = time().milliseconds();
 
         DeletionCondition shouldDelete = (segment, nextSegmentOpt) -> {
-            if (startMs < segment.largestTimestamp()) {
-                futureTimestampLogger.warn("{} contains future timestamp(s), 
making it ineligible to be deleted", segment);
+            long anchorTimestamp = segment.largestTimestamp();
+            if (startMs < anchorTimestamp) {
+                if (remoteLogEnabledAndRemoteCopyEnabled) {
+                    anchorTimestamp = segment.lastModified();

Review Comment:
   > Have we considered to use log.message.timestamp.after.max.ms to prevent 
future timestamps from leaking in in the first place?
   
   Yes, this can be used to prevent future data, but the fallback is still 
valuable for the existing future data.
   
   > The problem with lastModified is that it may not be accurate after 
reassignment or disk replacement.
   
   Yes, the file's last modified time is not immutable. Maybe we could find 
another anchor, like the copy-finished timestamp in remote metadata, to replace 
it. I will file a JIRA for it once I'm back at my computer.
   
   > I can remove this lastModified check
   
   @muralibasani pardon me, do we really need to revert it? lastModified is not 
immutable, but it won't cause "forever". The worst case is that the deletion 
gets deferred, and it is a bounded delay. By contrast, future data can be stuck 
forever, right?



-- 
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]

Reply via email to