urbandan commented on code in PR #19137:
URL: https://github.com/apache/kafka/pull/19137#discussion_r1983275116
##########
core/src/main/scala/kafka/log/UnifiedLog.scala:
##########
@@ -1522,6 +1522,9 @@ class UnifiedLog(@volatile var logStartOffset: Long,
val startMs = time.milliseconds
def shouldDelete(segment: LogSegment, nextSegmentOpt: Option[LogSegment]):
Boolean = {
+ if (startMs < segment.largestTimestamp()) {
+ warn(s"Segment with base offset $segment contains future timestamp")
Review Comment:
Going with your example, if you have that much data which is configured to
be removed with retention time, and they are blocked from removal, you are
already having a problem which you should be aware of.
I think the configs introduced in KIP-937 already achieve something similar
- if the user is aware of the problem with future timestamps, and went ahead to
configure the accepted timestamp range explicitly, they will not have an issue
with future timestamps. If we set the level to DEBUG, the user needs to be
aware of the concept, and set the log level explicitly. I think the added value
of this log is to have it by default, compared to encountering a disk full
issue, then investigating it.
Additionally, setting the level to DEBUG for UnifiedLog will add a lot more
output than just this one.
In short, if DEBUG is the only acceptable level, I'll gladly change it, but
it kind of defeats the purpose.
--
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]
