You are viewing a plain text version of this content. The canonical link for it is here.

Posted to jira@kafka.apache.org by "Senthilnathan Muthusamy (Jira)" <ji...@apache.org> on 2020/02/10 23:05:00 UTC

[jira] [Commented] (KAFKA-7061) Enhanced log compaction

    [ https://issues.apache.org/jira/browse/KAFKA-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17034004#comment-17034004 ] 

Senthilnathan Muthusamy commented on KAFKA-7061:
------------------------------------------------

[~guozhang] [~junrao] [~mjsax] looking to get this moving on... waiting for long time on the code review... can you please help moving. 12th is the code freeze date, right? are you guys thinking we can't make it for the 2.5 release?

> Enhanced log compaction
> -----------------------
>
>                 Key: KAFKA-7061
>                 URL: https://issues.apache.org/jira/browse/KAFKA-7061
>             Project: Kafka
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 2.5.0
>            Reporter: Luis Cabral
>            Assignee: Senthilnathan Muthusamy
>            Priority: Major
>              Labels: kip
>
> Enhance log compaction to support more than just offset comparison, so the insertion order isn't dictating which records to keep.
> Default behavior is kept as it was, with the enhanced approached having to be purposely activated.
>  The enhanced compaction is done either via the record timestamp, by settings the new configuration as "timestamp" or via the record headers by setting this configuration to anything other than the default "offset" or the reserved "timestamp".
> See [KIP-280|https://cwiki.apache.org/confluence/display/KAFKA/KIP-280%3A+Enhanced+log+compaction] for more details.
> +From Guozhang:+ We should emphasize on the WIKI that the newly introduced config yields to the existing "log.cleanup.policy", i.e. if the latter's value is `delete` not `compact`, then the previous config would be ignored.
> +From Jun Rao:+ With the timestamp/header strategy, the behavior of the application may need to change. In particular, the application can't just blindly take the record with a larger offset and assuming that it's the value to keep. It needs to check the timestamp or the header now. So, it would be useful to at least document this. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)