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
   2. HAS_NOT_JOINED: We'll use Optional.of(false), which only controllers can 
transition to.
   3. HAS_JOINED: We'll use Optional.of(true), which only controllers can 
transition to.
   
   The possible state transitions for controllers 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, 
or if the controller is the only member of the voter set when starting up.
   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 done it (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 during the lifetime of the 
process. Additionally, the controller process cannot go 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]

Reply via email to