Lucas Bradstreet created KAFKA-9338:
---------------------------------------
Summary: 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.4.0, 2.3.0, 2.2.0, 2.1.0
Reporter: Lucas Bradstreet
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)
