Hi Allan, Operations are pipelined and processed in order by the leader, so when the sync is queued behind the previous operations, we have that the responses to the previous updates will be flushed to the follower before the response to the sync. There is actually some degree of concurrency and some tricks we play with sync, but thinking of it as a pipeline of updates is the easiest way to reason about it.
-Flavio > On 24 Mar 2016, at 08:43, allanwin <[email protected]> wrote: > > Hi, All > I have a question about the Sync Operation: > //Asynchronous sync. Flushes channel between process and leader. > public void sync(final String path, VoidCallback cb, Object ctx) > > > I don't quite understand the purpose of this function. When I looked into > the code, I found out that(tell me if I'm wrong): > > > When Client send a Sync request to the server. The server will create a sync > request to the leader(if it is not the leader). > > > Then the leader looks his outstandingProposals list, if the list is empty, > then send back the sync to the follower immediately, and the the follower > send back the sync response to the client. > > > If the outstandingProposals is not empty, store the sync request with the > proposal id it is waiting for. > > > When the proposal which the sync request waiting for is ready to commit, send > commit to servers in the quorum, and then send back the sync to follower as > described above. > > > Is there some mechanism that can ensure that the commit message are processed > before the sync response send back to the client? > > > If there is, then all make sense, if not, after the sync call, the client > still can't make sure the next read request to the server can get the newest > data. >
