[
https://issues.apache.org/jira/browse/KAFKA-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17405420#comment-17405420
]
Jason Gustafson commented on KAFKA-13227:
-----------------------------------------
[~christo_lolov] Thanks, feel free to pick it up. I would suggest looking at
the test cases in `PartitionTest`. For example, `testRetryShrinkIsr` looks like
it already has most of the machinery you will need.
> Cancel pending AlterIsr requests after receiving LeaderAndIsr
> -------------------------------------------------------------
>
> Key: KAFKA-13227
> URL: https://issues.apache.org/jira/browse/KAFKA-13227
> Project: Kafka
> Issue Type: Improvement
> Reporter: Jason Gustafson
> Priority: Major
>
> Currently we do not cancel pending AlterIsr requests after the state has been
> updated through a LeaderAndIsr request received from the controller. This
> leads to log messages such as this
> {code}
> [2021-08-23 18:12:47,317] WARN [Partition __transaction_state-32 broker=3]
> Failed to enqueue ISR change state LeaderAndIsr(leader=3, leaderEpoch=3,
> isUncleanLeader=false, isr=List(3, 1), zkVersion=3) for partition
> __transaction_state-32 (kafka.cluster.Partition)
> {code}
> I think the only complication here is protecting against the AlterIsr
> callback which is executed asynchronously. To address this, we can move the
> `zkVersion` field into `IsrState`. When the callback is invoked, we can the
> existing state against the response state to decide whether to apply the
> change.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
