-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forwarding commands to the leader #190
Comments
Hey, glad to hear the library is working for you! I don't have any strong idea about this, but I would say that forwarding to the leader could be something that applications can implement outside this library. Typically applications consuming this library already implement some application-specific protocol, where they open a network port on every node for communicating with clients (or they proxy the raft-specific port). A non-leader node would accept changes, forward them to the leader via the application-specific protocol, wait for the leader to notify the commitment and then reply to the client. This might also be implemented in the library itself, but I feel it's something that every one might want to implement slightly differently. Not sure. |
I totally get the idea to keep the raft library simple and focus on the core functionality. There are other libraries, which have implemented something like this. But this might be a risk depending on the use case. The non-leader node forwarding a change cannot be sure, when his change will be added to the log. And depending on the use case this might be a bigger problem with conflicting changes. So I am fine to keep this kind of forwarding in the application layer. The only issue I have to keep this in application layer is the idea to implement a different communication between the node (for the forwarding). But we anyway think about extending the transport layer to allow custom data to make use of the existing transport layer. |
Right now we are using the library with great success. For our next extension we would need to be able to initiate log changes from any cluster member. Our idea would be to forward the change from the node to the leader and the leader would append it to the end of the log.
Are there already some design thoughts, how we might implement this ?
E.g. does it make sense to define an additional event_type ?
The text was updated successfully, but these errors were encountered: