[jira] [Commented] (KAFKA-8001) Fetch from future replica stalls when local replica becomes a leader

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16787263#comment-16787263 ] 

ASF GitHub Bot commented on KAFKA-8001:
---------------------------------------

colinhicks commented on pull request #6395: KAFKA-8001: Reset future replica fetcher when local log becomes leader.
URL: https://github.com/apache/kafka/pull/6395
 
 
   Upon becoming leader, the local replica can fail with `FENCED_LEADER_EPOCH` on its next fetch from the the future replica. In this condition, fetching is stalled until the next leader change. This patch avoids this scenario by removing then re-adding from `replicaAlterLogDirsManager` partitions for which both the local log is leader and a future replica exists.
   
   The test case asserts that such a partition is reset for fetching with the new leader epoch.
   
   ### Committer Checklist (excluded from commit message)
   - [ ] Verify design and implementation 
   - [ ] Verify test coverage and CI build status
   - [ ] Verify documentation (including upgrade notes)
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> Fetch from future replica stalls when local replica becomes a leader
> --------------------------------------------------------------------
>
>                 Key: KAFKA-8001
>                 URL: https://issues.apache.org/jira/browse/KAFKA-8001
>             Project: Kafka
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 2.1.0, 2.1.1
>            Reporter: Anna Povzner
>            Assignee: Colin Hicks
>            Priority: Critical
>
> With KIP-320, fetch from follower / future replica returns FENCED_LEADER_EPOCH if current leader epoch in the request is lower than the leader epoch known to the leader (or local replica in case of future replica fetching). In case of future replica fetching from the local replica, if local replica becomes the leader of the partition, the next fetch from future replica fails with FENCED_LEADER_EPOCH and fetching from future replica is stopped until the next leader change. 
> Proposed solution: on local replica leader change, future replica should "become a follower" again, and go through the truncation phase. Or we could optimize it, and just update partition state of the future replica to reflect the updated current leader epoch. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)