RFC: Client request pipelining about openraft HOT 9 OPEN

But why does it needs a D to create a ReplyConsumer with ReplyConsumer::from_request(D)?

The idea is to pass additional information "hidden" in D, which allows us to create the consumer. For example, the queue where to put the reply. Otherwise the reply consumer be stateless, which is not what we want. Alternatively, one could pass reference to SM or similar, where it could be hidden as well. But, some form of context for the reply consumer is needed.

From the method signature I do not see how a user get an instance of ReplyConsumer, then who will poll the Future of ReplyConsumer?

The user won't get the instance. The Future is polled within client_write(), same as today with oneshot::Receiver and client_write() would still return C::R. I.e., in the default case it will produce exactly the same binary code as we have today.

In the other case where the user implements ReplyConsumer, say, to post responses to a queue, the ReplyConsumer::request_completed() will be called with the response and then the user is free to do with the reply whatever he pleases (in this case, post the response to some queue, which was noted down when creating the ReplyConsumer based on the context).

from openraft.

👋 Thanks for opening this issue!

Get help or engage by:

• /help : to print help messages.
• /assignme : to assign this issue to you.

from openraft.

If the user uses the default implementation for ReplyConsumerType,

I have a general understanding of your concept.
It seems that ReplyConsumer is an internal component of Openraft.
Could you explain whether and how a user can decide to utilize the default implementation of ReplyConsumerType?

Additionally, would you be able to provide the method signatures for the revised client_write() and client_write_ff() functions?

from openraft.

No, ReplyConsumer is a public trait, which can be implemented by the user as needed (for example, we'd push replies into reorder buffer reordering them with read-only requests on the same client connection). But, to ease the implementation, I'm suggesting to provide something like DefaultReplyConsumer which implements ReplyConsumer and Future and internally uses oneshot channel. The type config would specify which reply consumer to use.

As for the signature, it would be:

    pub async fn client_write(
        &self,
        app_data: C::D,
    ) -> Result<ClientWriteResponse<C>, RaftError<C::NodeId, ClientWriteError<C::NodeId, C::Node>>>
    where C::ReplyConsumer: Future<Output = Result<
        ClientWriteResponse<C>,
        RaftError<C::NodeId, ClientWriteError<C::NodeId, C::Node>>
    >>;

    pub fn client_write_ff(&self, app_data: C::D);

The only suboptimal thing is that you can call client_write_ff also with the default reply consumer. OTOH, it would do exactly what it says - fire and forget. The response and any potential error would be lost, so probably not a big deal.

from openraft.

• I see that Openraft calls ReplyConsumer::request_completed() to send back the response. But why does it needs a D to create a ReplyConsumer with ReplyConsumer::from_request(D)?

• From the method signature I do not see how a user get an instance of ReplyConsumer, then who will poll the Future of ReplyConsumer?

from openraft.

Make sense.

The abstraction for queuing replies is an elegant design. 👍

from openraft.