It seems submitClientRequest only send to the local server. And the original purpose of this thread should be adjusted to the ratis client to auto-optimize local communication (avoid serde and send data via wire). It's somewhat like local actors' communications.
Best, tison. tison <[email protected]> 于2022年11月8日周二 00:33写道： > That said, I'm unsure whether submitClientRequest forwards the request to > other peers in the group by the current server internally. I think it's the > significant part whether a raft client is necessary. > > Best, > tison. > > > tison <[email protected]> 于2022年11月8日周二 00:26写道： > >> To Tsz Wo: >> >> Thank you! If I find a way to optionally introduce it, I'll come back >> with a patch. >> >> To William: >> >> Thanks for sharing the use case. It seems to resolve my requirements. >> However, I remember that Tsz Wo commented here[1] that we may still need a >> client to submit client requests properly. But it seems >> `RaftServer.submitClientRequest' >> is what I originally asked for. >> >> Best, >> tison. >> >> [1] https://lists.apache.org/thread/1joh4vhy9ytf4lmpr437rggkyyftw0kb >> >> >> William Song <[email protected]> 于2022年11月2日周三 20:22写道： >> >>> Hi tison, >>> >>> We also have an optimization for in-process scenarios in IOTDB, see [1]. >>> >>> We choose not to use a RaftClient, but to call >>> RaftServer.submitClientRequest directly. submitClientRequest is the entry >>> point for RaftClient requests.In this way we avoid >>> serialization/deserialization and network connection overheads.It is more >>> of a hack, and we loses some RaftClient features like retry / redirect. >>> >>> Hope it helps. >>> >>> Regards, >>> William >>> >>> [1] >>> https://github.com/apache/iotdb/blob/71c55e9abd35d4238b54bf232c17fb02e0ab66ca/consensus/src/main/java/org/apache/iotdb/consensus/ratis/RatisConsensus.java#L207 >>> >>> 2022年11月2日 13:38，Tsz Wo Sze <[email protected]> 写道： >>> >>> Hi tison, >>> >>> Just checked >>> https://grpc.github.io/grpc-java/javadoc/io/grpc/inprocess/InProcessChannelBuilder.html >>> , it is an ExperimentalApi. We may make it configurable so that users can >>> choose between NettyChannelBuilder or InProcessChannelBuilder. >>> >>> Tsz-Wo >>> >>> >>> On Wed, Nov 2, 2022 at 1:00 AM tison <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> I read that we're now always using: >>>> >>>> NettyChannelBuilder channelBuilder = >>>> NettyChannelBuilder.forTarget(target.getAddress()); >>>> >>>> to build the gRPC channel. However, if the ratis client runs in the >>>> same process, is it possible that we try to build an InProcessChannel first >>>> so that gain better performance? >>>> >>>> The motivation is that I'm considering exporting more ports for the >>>> ratis server (process) when writing downstream projects. In this case, when >>>> I'm talking to the ratis cluster (the replicated state machines), I need to >>>> use a ratis client so ratis can handle the consensus part. If I always >>>> initialize a Netty channel for every client, it looks like a significant >>>> performance concern. >>>> >>>> Best, >>>> tison. >>>> >>> >>>
