[
https://issues.apache.org/jira/browse/KAFKA-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004309#comment-17004309
]
Ismael Juma commented on KAFKA-9338:
------------------------------------
Cc [~hachikuji] [~cmccabe]
> Incremental fetch sessions do not maintain or use leader epoch for fencing
> purposes
> -----------------------------------------------------------------------------------
>
> Key: KAFKA-9338
> URL: https://issues.apache.org/jira/browse/KAFKA-9338
> Project: Kafka
> Issue Type: Bug
> Components: core
> Affects Versions: 2.1.0, 2.2.0, 2.3.0, 2.4.0
> Reporter: Lucas Bradstreet
> Priority: Major
>
> KIP-320 adds the ability to fence replicas by detecting stale leader epochs
> from followers, and helping consumers handle unclean truncation.
> Unfortunately the incremental fetch session handling does not maintain or use
> the leader epoch in the fetch session cache. As a result, it does not appear
> that the leader epoch is used for fencing a majority of the time. I'm not
> sure if this is only the case after incremental fetch sessions are
> established - it may be the case that the first "full" fetch session is safe.
> Optional.empty is returned for the FetchRequest.PartitionData here:
> [https://github.com/apache/kafka/blob/a4cbdc6a7b3140ccbcd0e2339e28c048b434974e/core/src/main/scala/kafka/server/FetchSession.scala#L111]
> I believe this affects brokers from 2.1.0 when fencing was improved on the
> replica fetcher side, and 2.3.0 and above for consumers, which is when client
> side truncation detection was added on the consumer side.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
