jsancio commented on code in PR #16900:
URL: https://github.com/apache/kafka/pull/16900#discussion_r1722529849


##########
raft/src/main/java/org/apache/kafka/raft/KafkaRaftClient.java:
##########
@@ -666,7 +666,6 @@ private void transitionToResigned(List<ReplicaKey> 
preferredSuccessors) {
         fetchPurgatory.completeAllExceptionally(
             Errors.NOT_LEADER_OR_FOLLOWER.exception("Not handling request 
since this node is resigning"));
         quorum.transitionToResigned(preferredSuccessors);
-        maybeFireLeaderChange();

Review Comment:
   > If we are not notifying the RaftListener-s about the loss in leadership 
here, and we're not doing it in pollListeners, where do we do it?
   
   First, the raft has not lost leadership. It is resigning but staying on the 
same epoch. Raft stops accepting write operations while it waits for another 
replica to increase the epoch and win the leadership.
   
   > Or Is it the case that we do not notify about this event any more and 
simply let writes fail?
   
   Yeah. The next write will fail and the controller will become inactive. But 
raft will not increase the epoch and try to win the leadership.
    
   > Assuming a listener does not attempt a write, when will they learn about 
the new epoch? Once the raft client becomes a candidate in the new epoch?
   
   Yes. Once another voter increases the epoch and becomes a candidate.
   
   



-- 
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: jira-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to