> However, still I don't know what "watch an index" actually means. How can I obtain the index in the first place? What condition I will receive a one-shot response from?
A log index can be obtained by RaftClientReply.getLogIndex(), which returns the raft log index corresponding to a write request. The work flow is like below: 1. A client sends a (write) request and then gets back a RaftClientReply r -- at that moment the request may only have been replicated to a MAJORITY of servers as specified by the Raft Algorithm. 2. A user application may have a more strict replication requirement. For example, it may want the request to be replicated to ALL the servers, instead of a MAJORITY. It may call watch(r.getLogIndex(), ReplicationLevel.ALL) in order to watch for the replication ALL condition. We also have MAJORITY_COMMITTED and ALL_COMMITTED replication levels. COMMITTED means that the server's commit-index has been increased at least the watched index. Hope it helps. Tsz-Wo On Fri, Sep 30, 2022 at 5:43 PM tison <[email protected]> wrote: > Hi Tsz-Wo, > > Thanks for your reply! > > I think in this way I can implement a one-shot watcher. > > The similar functionality in etcd defines as: > > rpc Watch(stream WatchRequest) returns (stream WatchResponse); > > ... and this is why I use "full-duplex server-client communication" in the > subject - Is it possible for a Ratis client opens a connection to do > something like this? > > > AsyncApi.watch > > Yes. IIRC I asked questions about this "watch" function years ago and > understand it's not "watch a key" :) > > However, still I don't know what "watch an index" actually means. How can > I obtain the index in the first place? What condition I will receive a > one-shot response from? > > Best, > tison. > > > Tsz Wo Sze <[email protected]> 于2022年9月30日周五 15:17写道： > >> Hi tison, >> >> Since Ratis server is asynchronous event-driven. We may implement "watch >> a key" using the AsyncApi [1]: >> 1. Client sends a "watch a key" request by client.a >> sync().sendReadOnly(..). >> 2. StateMachine won't complete the future until the key satisfies the >> watch condition. >> >> One problem is that the async read calls in Ratis are ordered. Thus, >> the other ordered async calls sent by the same client would not be >> completed before the "watch a key" request is completed. Of course, we >> may work around it by creating a new client. A better solution is to >> support unordered async read (a new feature) in Ratis. >> >> Note that Ratis already supports unordered AsyncApi.watch(..), which can >> watch for the replication level of the given log index. Therefore, it is >> easy to add the new feature for supporting unordered async read. >> >> What do you think? >> >> Tsz-Wo >> >> [1] >> https://github.com/apache/ratis/blob/master/ratis-client/src/main/java/org/apache/ratis/client/api/AdminApi.java >> >> >> On Fri, Sep 30, 2022 at 2:21 PM tison <[email protected]> wrote: >> >>> Hi, >>> >>> I'm trying to write a replicated map based on Ratis. >>> >>> One thing that blocks me here is that I'm trying to implement something >>> like "watch a key". While Ratis support basic RPC between server and >>> client, it's a one-shot RPC call. I have two ideas here but both seems not >>> easy to implement: >>> >>> 1. Take the client connection and send back key changes even if the >>> client doesn't round-robin query it. However, the Rpc details in under >>> encapsulation and never intend to be used. >>> 2. Wrapper an RMap server over the Ratis server. However, in this case, >>> It's the RMap server that should be responsible for initiating and managing >>> the connection. Ratis server encapsulates this detail and the only way I >>> can imagine is the RMap server as a proxy, but it's quite clumsy to have >>> one more hop. >>> >>> Looking forward to your ideas. >>> >>> Best, >>> tison. >>> >>
