You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Christo Lolov (Jira)" <ji...@apache.org> on 2021/09/11 06:32:00 UTC

[jira] [Commented] (KAFKA-13227) Cancel pending AlterIsr requests after receiving LeaderAndIsr

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

Christo Lolov commented on KAFKA-13227:
---------------------------------------

[~hachikuji] Apologies for the delay, I wasn't able to find the time to look further into this before today. I read KIP-497, have been going through the code and I am slightly confused. As far as I can tell, the above WARN message is logged whenever a newer _AlterIsr_ request is enqueued to be sent and we find a still unsent _AlterIsr_ request for the same _topicPartition_ in the _unsentIsrUpdates_ map, which we overwrite and forget about. Since this happens before we send the older _AlterIsr_ request do we have to take care of its callback? Or am I misunderstanding the code?

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