RATIS-2350. Fix readAfterWrite bugs. #1311
Conversation
SzyWilliam
left a comment
SzyWilliam
left a comment
There was a problem hiding this comment.
Beautiful work! Feels like reading math essay here.
Looks good to me excepts for a small question ;)
| if (current > lastApplied) { | ||
| readIndexQueue.complete(current); | ||
| } |
There was a problem hiding this comment.
I vaguely remember this double check is to prevent race condition, see #958. We may still face a race condition here because ReadIndexQueue.add is not totally synchronized. How about moving the entire ReadIndexQueue.add to synchronzied?
There was a problem hiding this comment.
@SzyWilliam , thanks for reminding me about RATIS-1927!
In this pr, the check is moved to a synchronized block in ReadIndexQueue.add(..) and lastAppliedIndex is also updated synchronously. So, it won't have a race condition anymore.
OneSizeFitsQuorum
left a comment
OneSizeFitsQuorum
left a comment
There was a problem hiding this comment.
LGTM
I see that linearizable is the strongest consistency level. Write-after-read consistency is somewhat weaker. For example, if client A first writes at index 1, and then client B writes at index 2, when client A queries the data, for linearizable, it must wait until the state machine has applied index 2 before it can query and get the correct result. However, for write-after-read consistency, the state machine only needs to apply up to index 1, and it can return the result immediately.
|
@SzyWilliam , please see if you would take a second look. Otherwise, let's merge it tomorrow. |
|
@SzyWilliam , @OneSizeFitsQuorum , thanks for reviewing this! |
3 participants
See RATIS-2350.