[
https://issues.apache.org/jira/browse/KAFKA-6150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16535484#comment-16535484
]
Henry Cai commented on KAFKA-6150:
----------------------------------
>From the call stack:
KafkaApis.handleDeleteRecordsRequest -> ReplicaManager.deleteRecords ->
ReplicaManager.deleteRecordsOnLocalLog -> Partition.deleteRecordsOnLeader ->
Replica.maybeIncrementLogStartOffset -> Log.maybeIncrementLogStartOffset
You can add a overloaded argument in that path to suppress the two INFO
loggings.
Or maybe just change those two INFO logging to DEBUG loggings, moving start
offset is not that eventful.
> Make Repartition Topics Transient
> ---------------------------------
>
> Key: KAFKA-6150
> URL: https://issues.apache.org/jira/browse/KAFKA-6150
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Guozhang Wang
> Assignee: Guozhang Wang
> Priority: Major
> Labels: operability
> Fix For: 1.1.0
>
>
> Unlike changelog topics, the repartition topics could just be short-lived.
> Today users have different ways to configure them with short retention such
> as enforce a short retention period or use AppendTime for repartition topics.
> All these would be cumbersome and Streams should just do this for the users.
> One way to do it is use the “purgeData” admin API (KIP-107) such that after
> the offset of the input topics are committed, if the input topics are
> actually repartition topics, we would purge the data immediately.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
