bitflicker64 commented on code in PR #3383:
URL: https://github.com/apache/hugegraph/pull/3383#discussion_r4340523517
##########
hugegraph-pd/hg-pd-service/src/main/java/org/apache/hugegraph/pd/service/KvServiceGrpcImpl.java:
##########
@@ -158,6 +158,12 @@ public void get(K request, StreamObserver<KResponse>
responseObserver) {
KResponse response;
KResponse.Builder builder = KResponse.newBuilder();
try {
+ /*
+ * A leader elected a moment ago may not have applied every
committed write yet,
+ * and a Server that read such a value would cache schema older
than a revision it
+ * acknowledged: read after a ReadIndex barrier.
+ */
+ RaftEngine.getInstance().waitReadIndex();
Review Comment:
Agreed, the point is real for these two reads, and it is narrow: the wait
ends at `raft.rpc-timeout`, and the leader steps down about 1 s after losing
quorum (jraft's default election timeout), so filling all 600 workers needs
about 600 reads in that second. Master already holds the same workers on the
same outage: every `RaftKVStore` write waits with no timeout until the
step-down, and the id reads from #3368 use this barrier. So I opened #3389 to
handle the three paths together, with returning the ReadIndex future and
answering from a small executor as one direction. No change here.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
