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. >>> >> >>
