https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-1880 controller <p>RAFT section 5.3 states that:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>If desired, the protocol can be optimized to reduce the number of rejected AppendEntries RPCs. For example, when rejecting an AppendEntries request, the follower can include the term of the conflicting entry and the first index it stores for that term. With this information, the leader can decrement nextIndex to bypass all of the con- flicting entries in that term; one AppendEntries RPC will be required for each term with conflicting entries, rather than one RPC per entry. In practice, we doubt this opti- mization is necessary, since failures happen infrequently and it is unlikely that there will be many inconsistent en- tries.</pre> </div></div> <p>We currently do not implement this optimization, but it could be useful. From implementation perspective, rather than expanding AppendEntries directly with this information, we should add a subclass, which is used when the follower determines this additional information is useful for leader to skip some entries.</p> CONTROLLER-1880

Include conflicting term informantion in AppendEntriesReply

Improvement Low Open Unresolved Unassigned Robert Varga Wed, 9 Jan 2019 10:46:41 +0000 Thu, 25 Jun 2020 11:46:50 +0000 clustering 0 2 <p>We've already implemented other optimizations to avoid the slow path of decrementing the next index, some of it due to the in-memory log trimming and replicatedToAllIndex which isn't covered by raft. The above optimization would only help in the case where the leader's previous log entry exists in the follower's log but the terms don't match (which wouldn't cover the case in <a href="https://git.opendaylight.org/gerrit/#/c/79351" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/79351</a>). So currently, we'd only hit the slow path if the follower had accumulated more uncommitted entries from a prior term than the number of new entries from the leader's new term. The above optimization would help in that case although it wouldn't be common.</p> <p>BTW - the new info would be added to AppendEntriesReply.</p> Development Rank 0|i03ly7: