Another direction can be, is it possible to submit a request to RaftServer locally, and thus not need to pipe a request from replicated map's client, map's server (i.e. RatisClient), and RatisServer?
Best, tison. tison <[email protected]> 于2022年9月30日周五 19:03写道： > Thank you. I'll check the technical details. > > For the application framework, I find a possible way to add an external > watch manager who gets notified from callbacks registered to the state > machine. Although, this way asks the client to establish one more > connection to the watch manager (even if in the same process, different > port). > > Best, > tison. > > > Tsz Wo Sze <[email protected]> 于2022年9月30日周五 18:30写道： > >> > 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. >>>>> >>>>
