[ 
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)

Reply via email to