[
https://issues.apache.org/jira/browse/KAFKA-15221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gustafson resolved KAFKA-15221.
-------------------------------------
Fix Version/s: (was: 3.5.2)
Resolution: Fixed
> Potential race condition between requests from rebooted followers
> -----------------------------------------------------------------
>
> Key: KAFKA-15221
> URL: https://issues.apache.org/jira/browse/KAFKA-15221
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 3.5.0
> Reporter: Calvin Liu
> Assignee: Calvin Liu
> Priority: Blocker
> Fix For: 3.7.0
>
>
> When the leader processes the fetch request, it does not acquire locks when
> updating the replica fetch state. Then there can be a race between the fetch
> requests from a rebooted follower.
> T0, broker 1 sends a fetch to broker 0(leader). At the moment, broker 1 is
> not in ISR.
> T1, broker 1 crashes.
> T2 broker 1 is back online and receives a new broker epoch. Also, it sends a
> new Fetch request.
> T3 broker 0 receives the old fetch requests and decides to expand the ISR.
> T4 Right before broker 0 starts to fill the AlterPartitoin request, the new
> fetch request comes in and overwrites the fetch state. Then broker 0 uses the
> new broker epoch on the AlterPartition request.
> In this way, the AlterPartition request can get around KIP-903 and wrongly
> update the ISR.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
