[
https://issues.apache.org/jira/browse/RATIS-2350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18048484#comment-18048484
]
Ivan Andika commented on RATIS-2350:
------------------------------------
However, for this following example
!image-2025-12-31-10-28-28-475.png|width=749,height=339!
We can only generate a linearizable order if Read 1 and Read 2 returns the same
color (either both return "garnet" or both return "brick"). In this case since
Write 1 and Write 2 are concurrent writes (there are no real-time constraints
between Write 1 and Write 2), if Write 1 wins, both Read 1 and Read 2 will
return "garnet", but if Write 2 wins, both Read 1 and Read 2 will return
"brick".
However, if Read 1 and Read 2 return different colors, we cannot generate a
linearizable order
* Read 1 returns “garnet”, but Read 2 returns “brick”
* Read 1 returns “brick”, but Read 2 returns “garnet"
This is because the value constraints is violated
* If Write 1 wins, but one of the subsequent read returns "brick", it will
violate the value constraint, since the read should not read the stale "brick"
* If Write 2 wins, but one of the subsequent read returns "garnet", it will
violate the value constraint, since the read should not read the stale "garnet"
Therefore, I'm not sure whether the strong "read-after-write" consistency is
also linearizable.
> Fix readAfterWrite bugs
> -----------------------
>
> Key: RATIS-2350
> URL: https://issues.apache.org/jira/browse/RATIS-2350
> Project: Ratis
> Issue Type: Bug
> Components: server
> Reporter: Tsz-wo Sze
> Assignee: Tsz-wo Sze
> Priority: Major
> Fix For: 3.3.0
>
> Attachments: image-2025-12-31-10-28-28-475.png, screenshot-1.png,
> screenshot-2.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> There are bugs in handling readAfterWrite requests:
> # In LeaderStateImpl.getReadIndex(..), it should use the max of
> readAfterWriteConsistentIndex and commitIndex.
> # In WriteIndexCache.add(..), it should combine the current future with
> previous future when the previous future exists.
> Improvement:
> - Add lastAppliedIndex to ReadIndexQueue
> - Replace Consumer<Long> with LongConsumer
> Bug in tests:
> - In LinearizableReadTests.runTestReadAfterWrite(..), it tries to assert the
> following:
> {quote}Assertion: _read-after-write is more consistent than linearizable read_
> {quote}
> Recall the definitions:
> {quote}Read-after-write: _Within the same client, the read called after write
> must able to see the change of the write._
> {quote}
> {quote}Linearizable read: _The read is linearizable (i.e. it won't read stale
> data)._
> {quote}
> Suppose readIndex is 9 and writeIndex is 10. By definition, read-after-write
> must return any state at log index A >= 10 while linearizable read must
> return any state at log index L >= 9. The assertion incorrectly check if A >=
> L, which is not a requirement. It is perfectly fine, for example, if A=11 <
> L=12.
> ----
> Original Summary: TestReadOnlyRequestWithGrpc may fail intermittently
> Original Description:
> {code:java}
> org.apache.ratis.grpc.TestReadOnlyRequestWithGrpc.testReadAfterWrite -- Time
> elapsed: 1.572 s <<< FAILURE!
> org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
> at
> org.apache.ratis.ReadOnlyRequestTests.testReadAfterWriteImpl(ReadOnlyRequestTests.java:314)
> at
> org.apache.ratis.server.impl.MiniRaftCluster$Factory$Get.runWithNewCluster(MiniRaftCluster.java:143)
> at
> org.apache.ratis.server.impl.MiniRaftCluster$Factory$Get.runWithNewCluster(MiniRaftCluster.java:121)
> at
> org.apache.ratis.ReadOnlyRequestTests.testReadAfterWrite(ReadOnlyRequestTests.java:289)
> {code}
> It failed 8 in [this 10x10
> run|https://github.com/apache/ratis/actions/runs/19023405871/job/54322726144].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
