[
https://issues.apache.org/jira/browse/KAFKA-18377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17909207#comment-17909207
]
Alyssa Huang edited comment on KAFKA-18377 at 1/2/25 7:38 AM:
--------------------------------------------------------------
Thanks [~frankvicky]! Sorry for not indicating this clearly on the ticket, but
this one definitely relies on KAFKA-17642 which will make Resigned transition
to Unattached with epoch + 1 instead of Candidate.
Thinking about it more, adding a short circuit may reduce the chance of a
different replica from being elected (which could be desirable if this replica
is behaving poorly). Let's say all replicas have received the end quorum
request. Any "preferred candidates" designated in the end quorum epoch request
may have their fetch timeouts overridden (the most preferred will get
overridden to 0). Only the most preferred successor gets a guaranteed chance to
start an election before the resigned replica transitions to Unattached and
then Prospective immediately with this short circuit. Not only does this defeat
the purpose of the preferred successor list being greater than 0, this doesn't
even give the most preferred successor a good chance to get elected because its
epoch will be lower than the resigned replica's after it transitions to
unattached -
Time=0 (Replica1 resigns and sends end quorum requests out)
- Replica1 - (Resigned, epoch=5)
- Replica2 - (Follower, epoch=5, leaderId=1)
Time=1 (Replica1 receives end quorum response from all replicas)
- Replica1 - (Unattached, epoch=6)
- Replica2 - (Prospective, epoch=5)
Once Replica1 sends a fetch to Replica2, or Replica2 receives any response from
Replica1 for that matter, Replica2 will need to bump its epoch.
I'll update this thread tomorrow after discussing with [~jsancio]
was (Author: alyssahuang):
Thanks [~frankvicky]! Sorry for not indicating this clearly on the ticket, but
this one definitely relies on KAFKA-17642 which will make Resigned transition
to Unattached with epoch + 1 instead of Candidate.
Thinking about it more, adding a short circuit may reduce the chance of a
different replica from being elected (which could be desirable if this replica
is behaving poorly). Let's say all replicas have received the end quorum
request. Any "preferred candidates" designated in the end quorum epoch request
may have their fetch timeouts overridden (the most preferred will get
overridden to 0). Only the most preferred successor gets a guaranteed chance to
start an election before the resigned replica transitions to Unattached and
then Prospective immediately with this short circuit. Not only does this defeat
the purpose of the preferred successor list being greater than 0, this doesn't
even give the most preferred successor a good chance to get elected because its
epoch will be lower than the resigned replica's after it transitions to
unattached -
Time=0 (Replica1 resigns and sends end quorum requests out)
- Replica1 - (Resigned, epoch=5)
- Replica2 - (Follower, epoch=5, leaderId=1)
Time=1 (Replica1 receives end quorum response from all replicas)
- Replica1 - (Unattached, epoch=6)
- Replica2 - (Prospective, epoch=5)
Once Replica1 sends a fetch to Replica2, or Replica2 receives any response from
Replica1 for that matter, Replica2 will need to bump its epoch.
I'll update this thread tomorrow after discussing with [~jsancio]
> pollResigned can short circuit to unattached on receiving all endquorum acks
> ----------------------------------------------------------------------------
>
> Key: KAFKA-18377
> URL: https://issues.apache.org/jira/browse/KAFKA-18377
> Project: Kafka
> Issue Type: Improvement
> Reporter: Alyssa Huang
> Assignee: TengYao Chi
> Priority: Minor
>
> Resigned state keeps track of `unackedVoters` and on pollResigned only sends
> endQuorum requests to those voters. Right now it is not used to short circuit
> the transition to Unattached once the set is empty.
> It would be useful to short circuit this to allow the replica to discover any
> new leader more quickly (say in the case that the node was removed from
> quorum, the new leader would not be sending beginquorum requests to this
> node).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
