Xushaohong commented on code in PR #745:
URL: https://github.com/apache/ratis/pull/745#discussion_r971692476
##########
ratis-server/src/main/java/org/apache/ratis/server/leader/LogAppenderBase.java:
##########
@@ -158,6 +158,11 @@ private TermIndex getPrevious(long nextIndex) {
}
}
+ final long raftLogLastPurgedIndex = getRaftLog().getStartIndex() - 1;
+ if (raftLogLastPurgedIndex == previousIndex) {
+ return TermIndex.valueOf(server.getInfo().getCurrentTerm(),
raftLogLastPurgedIndex);
Review Comment:
> > Since A's raft log.startIndex had not changed, A will still try to
append the log starting from 3402406, which caused the loop.
>
> This looks correct -- the Leader A was sending heartbeats. It is supposed
to work like that -- A will keep sending heartbeats until B has installed a
snapshot.
Just to clarify the scenario:
A's notifyInstallSnapshot tells B to install at its first available Term
index (t:9, i:3402406)
B returns ALREADY_INSTALLED, current snapshot index: 3402405
Then A sends entries starting from 3402406, but A cannot find the **previous
entry** 3402405 from the raft log or from the latest SM's snapshot.
The reason is A's snapshot info is not the one that causes the purging raft
log to 3402405.
According to the log, A's snapshotIndex should be (t:9, i:3407893), which
does not equal 3402405.
No matter how many times A restarts, as long as A's raft log's start index
is not updated, the problem will remain.
So the follower is not working. I am afraid by default we do not use
**purgeUptoSnapshotIndex**, the purgeIndex will not be updated.
--
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]
