Comments (9)
But why does it needs a
D
to create aReplyConsumer
withReplyConsumer::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 theFuture
ofReplyConsumer
?
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 aD
to create aReplyConsumer
withReplyConsumer::from_request(D)
? -
From the method signature I do not see how a user get an instance of
ReplyConsumer
, then who will poll theFuture
ofReplyConsumer
?
from openraft.
Make sense.
The abstraction for queuing replies is an elegant design. 👍
from openraft.
Related Issues (20)
- Feature: Monoio Runtime HOT 5
- Add sync primitives to `AsyncRuntime` trait HOT 1
- Add `AsyncRuntime::oneshot` HOT 2
- Propose stream-based Replication of Log Entries HOT 2
- Dynamic Cluster Membership HOT 5
- Release 0.9 HOT 2
- Killing the leader of a cluster generates excessive network attempts for replicating log entries HOT 4
- main branch cannot compile, please update dependency rocksdb version HOT 2
- move trait method: from `RaftLogStorage` to `RaftLogReader::read_vote()` HOT 2
- Tracking issue for examples update HOT 1
- Update example `raft-kv-memstore` to use `storage-v2` HOT 2
- Update example `raft-kv-rocksstore` to use `storage-v2` HOT 1
- Move examples into the workspace HOT 1
- Install Snapshot v1 api HOT 3
- Observe state changes in a Raft node HOT 6
- Split metrics into data metrics and server metrics HOT 5
- About automatic remove HOT 3
- Backing up the WAL HOT 6
- Raft Core Panicking HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openraft.