Yongzao Dan created RATIS-2547:
----------------------------------
Summary: Advance repliedIndex before completing held write replies
in ReplyFlusher
Key: RATIS-2547
URL: https://issues.apache.org/jira/browse/RATIS-2547
Project: Ratis
Issue Type: Bug
Components: server
Reporter: Yongzao Dan
When `raft.server.read.option` uses `REPLIED_INDEX`, `ReplyFlusher` batches
write replies and advances the leader's replied index. The current
implementation invokes each held reply callback while computing the max flushed
log index. That means a write reply can be completed and returned to the client
before `ReplyFlusher` advances `repliedIndex` to include the corresponding log
index.
This ordering creates a race for read-after-write workloads. A client may
observe a successful write reply, then issue a linearizable read routed through
`REPLIED_INDEX` while the leader's `repliedIndex` still lags behind the
completed write. The read can wait unnecessarily or time out even though the
write reply has already been released.
Proposed fix:
- Store the log index separately from the reply completion callback in
`ReplyFlusher`.
- Compute the max flushed log index without completing replies.
- Advance `repliedIndex` first.
- Complete the held reply callbacks only after `repliedIndex` has been updated.
- Make `LeaderTracer.removePendingRequest` tolerate a null pending request,
since some code paths can remove no pending request while still completing
cached replies.
Test plan:
- Add `TestReplyFlusher#testAdvanceRepliedIndexBeforeCompletingReplies`.
- Exercise the replied-index follower read path via
`TestLinearizableReadRepliedIndexWithGrpc#testFollowerLinearizableReadParallel`.
- Run `mvn -pl ratis-server,ratis-test -am
-Dtest=TestReplyFlusher,TestLinearizableReadRepliedIndexWithGrpc test`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
