[ https://issues.apache.org/jira/browse/KAFKA-12177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jun Rao resolved KAFKA-12177. ----------------------------- Fix Version/s: 3.0.0 Assignee: Lucas Bradstreet Resolution: Fixed merged the PR to trunk > Retention is not idempotent > --------------------------- > > Key: KAFKA-12177 > URL: https://issues.apache.org/jira/browse/KAFKA-12177 > Project: Kafka > Issue Type: Improvement > Reporter: Lucas Bradstreet > Assignee: Lucas Bradstreet > Priority: Minor > Fix For: 3.0.0 > > > Kafka today applies retention in the following order: > # Time > # Size > # Log start offset > Today it is possible for a segment with offsets less than the log start > offset to contain data that is not deletable due to time retention. This > means that it's possible for log start offset retention to unblock further > deletions as a result of time based retention. Note that this does require a > case where the max timestamp for each segment increases, decreases and then > increases again. Even so it would be nice to make retention idempotent by > applying log start offset retention first, followed by size and time. This > would also be potentially cheaper to perform as neither log start offset and > size retention require the maxTimestamp for a segment to be loaded from disk > after a broker restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)