ivandika3 commented on code in PR #1589:
URL: https://github.com/apache/ratis/pull/1589#discussion_r4033958457
##########
ratis-server-api/src/main/java/org/apache/ratis/server/RaftServer.java:
##########
@@ -82,6 +83,27 @@ default RaftPeer getPeer() {
/** @return the information about this division. */
DivisionInfo getInfo();
+ /**
+ * Create a {@link NotLeaderException} using the current division state.
+ *
+ * <p>The suggested leader and peers are best-effort hints. The suggested
+ * leader is null if this division is not running or if its current leader
+ * ID is unknown or is the ID of this division.</p>
+ */
+ default NotLeaderException newNotLeaderException() {
+ if (!getInfo().getLifeCycleState().isRunning()) {
+ return new NotLeaderException(getMemberId(), null, null);
+ }
+ RaftPeerId leaderId = getInfo().getLeaderId();
+ if (leaderId == null || leaderId.equals(getId())) {
+ // No idea about who is the current leader. Or the peer is the current
+ // leader, but it is about to step down. set the suggested leader as
null.
Review Comment:
Thanks @amaliujia for the review.
> It seems to be an issue when a user calls newNotLeaderException on a true
leader, and in this case it shouldn't be as an exception, but should return a
status to indicate this current leader is a true leader, etc.
Yes, I also thought about this, but since SCM calls `checkLeader` before
every `triggerNotLeaderException` then we simply need to handle the
`NotLeaderException` generation. The `newNotLeaderException` will still get
generated even if the current peer is a true leader. I have added the Javadoc
for this.
> If we choose to expose this logic to application, I think we need a
checkLeader API so it should support:
Good idea, I added a support for `checkLeaderReady`. This would support
check the leadership and leadership readiness. I don't include the
`LeaderSteppingDownException` for now. Previously Ozone SCM converted all to
`NotLeaderException` even if leader is not ready yet. The `checkLeaderReady`
would allow SCM client to not failover by throwing `LeaderNotReadyException`.
Regarding "a server is a follower but it believes it is a leader" and "a
server is a follower and it knows it is not a leader", we cannot differentiate
this without either leader doing a majority heartbeat check which can kill
performance. So since Ozone does not guarantee linearizability in all cases, I
think just checking the leader status locally is enough.
Ideally, Ozone to submit all requests to Ratis, even for reads (that will be
handled by `StateMachine#query`) so Ozone doesn't need to check leadership,
etc. However, from https://github.com/apache/ratis/pull/1448, we discovered
that the protobuf serde in the current Raft submit has very high overhead,
among other reasons.
--
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]