[
https://issues.apache.org/jira/browse/KAFKA-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gustafson resolved KAFKA-9338.
------------------------------------
Fix Version/s: 2.5.0
Resolution: Fixed
Marking this just as 2.5 for now. If we don't find any problems, we will
backport to 2.4 at least.
> 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
> Assignee: Jason Gustafson
> Priority: Major
> Fix For: 2.5.0
>
>
> 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)
