Jason Gustafson reassigned KAFKA-9338:

    Assignee: Jason Gustafson

> 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
> 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

Reply via email to