You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by GitBox <gi...@apache.org> on 2020/12/04 17:51:49 UTC

[GitHub] [kafka] tombentley commented on pull request #9441: KAFKA-10614: Ensure group state (un)load is executed in the submitted order

tombentley commented on pull request #9441:
URL: https://github.com/apache/kafka/pull/9441#issuecomment-738925531


   You're right @guozhangwang, `ScheduledFutureTask` contains a sequence number to break ties, so the executor _is_ FIFO. So you're saying that the wrong network thread handling one of these two LeaderAndISR acquires `replicaStateChangeLock` first, right? If that's the case then might a similar problem affect the `txnCoordinator` too?
   
   I updated the PR if you want to take another look, but I still need to address synchronization, since although `onLeadershipChange` is executed with `ReplicaManager.replicaStateChangeLock`, `onResignation` is also called via `handleStopReplicaRequest`. Perhaps it's enough to make `onResignation` synchronized.


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