[
https://issues.apache.org/jira/browse/KAFKA-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17416349#comment-17416349
]
Jason Gustafson commented on KAFKA-13227:
-----------------------------------------
[~christo_lolov] When we have updated the ISR state after receiving a
LeaderAndIsr request, we have an opportunity to cancel any inflight AlterIsr
requests since they would be doomed to fail. When we do this, we want make sure
that the callback could not be mistakenly applied. We protect against this
currently by checking in the callback whether the ISR state matches the pending
state we expected when the AlterIsr request was enqueued. However, the check is
a little weak since it does not include the update version, so it is
conceivable that we could enqueue up the same change a second time. This is
probably not the only way to do it. Maybe we just need a flag in the callback
to indicate that the request was cancelled.
> 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
> Assignee: Christo Lolov
> 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)
