kevin-wu24 commented on code in PR #20859:
URL: https://github.com/apache/kafka/pull/20859#discussion_r2565350148
##########
raft/src/main/java/org/apache/kafka/raft/KafkaRaftClient.java:
##########
@@ -222,6 +222,8 @@ public final class KafkaRaftClient<T> implements
RaftClient<T> {
private volatile RemoveVoterHandler removeVoterHandler;
private volatile UpdateVoterHandler updateVoterHandler;
+ private volatile boolean hasJoined = false;
Review Comment:
I have an idea how we can model this state properly. We can use an
Optional<Boolean>. Now we can represent 3 distinct "hasJoined" states:
1. `UNKNOWN`: We'll use Optional.empty(), which applies to all nodes on
startup, including brokers. Brokers, static controller quorums, or dynamic
controllers without auto-join enabled will always remain in this state.
2. `HAS_NOT_JOINED`: We'll use Optional.of(false), which only controllers
with auto-join can transition to.
3. `HAS_JOINED`: We'll use Optional.of(true), which only controllers with
auto-join can transition to.
The possible state transitions for controllers who have auto-join enabled
are:
1. `UNKNOWN -> HAS_JOINED`: This occurs when the controller handles a fetch
response, is "up-to-date" with the HWM, and discovers it IS in the voter set.
This transition can also occur when the controller is the only member of the
voter set when starting up (standalone controller), or if the controller wins
the initial election.
2. `UNKNOWN -> HAS_NOT_JOINED`: This occurs when the controller handles a
fetch response, is "up-to-date" with the HWM, and discovers it is NOT in the
voter set.
3. `HAS_NOT_JOINED -> HAS_JOINED`: This also occurs when the controller
handles a fetch response, and discovers it is in the voter set. However, we do
not need to do the HWM check here because the transition from `UNKNOWN ->
HAS_NOT_JOINED` has already made the check (i.e. we know we are up to date).
Importantly, state transition 2 can only occur once in the lifetime of the
controller, because we cannot transition to UNKNOWN from any state during the
lifetime of the process. Additionally, we cannot transition from `HAS_JOINED ->
HAS_NOT_JOINED` ever.
`shouldSendAddOrRemoveVoter` will be conditioned on the state being
`HAS_NOT_JOINED`. Therefore, the two invariants above mean that, during its
process lifetime, a controller will not try to auto-join again after being
removed from the voter set.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
