junrao commented on code in PR #22873:
URL: https://github.com/apache/kafka/pull/22873#discussion_r4097159048
##########
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:
The problem with lastModified is that it may not be accurate after
reassignment or disk replacement.
Have we considered to use
[log.message.timestamp.after.max.ms](https://kafka.apache.org/43/configuration/broker-configs/#brokerconfigs_log.message.timestamp.after.max.ms)
to prevent future timestamps from leaking in in the first place?
--
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]
