add watch raft log #1354
add watch raft log #1354
Conversation
|
Thanks for your contribution, seems straightforward enough. So the idea is clients would poll this endpoint? It seems like you also handle the case where the log index doesn't exist, due to a log truncation (which is good). But doesn't this very issue limit the usefulness of this endpoint substantially? Unless the client never misses a log, the client will miss changes. If you want the client to receive a complete record of the changes, it better never go down for any extended period. Do you agree? |
|
The first time the client gets the latest index number from index 0, the client is not concerned about previous raft log changes. The client then continuously monitors index changes in order to obtain changes in raft logs, and the client continuously updates the index number of the latest raft logs |
|
What is there is a break? For example the client crashes, and a log truncation takes place before the client comes back up. The client will have missed a set of logs in that case. Can you suggest an application where this feature in still useful? |
|
If the client crashes, when the client restarts, it only needs to obtain the latest data from the database. This scenario is suitable for the client not to persist the data in the database. |
|
OK, thanks for that. This is something I'll consider after I release 8.0. I need to focus on that work for now. |
|
You can consider the watch scheme of etcd, which is better |
|
In the advent of a client crash, it would be useful if the client could call this endpoint again upon recovering with a Regarding the protocol, http polling seems a bit unoptimized. Server-Sent Events (SSE) might be an alternative, there is no incurred latency, as the connection is persistent. There is also the advantage of not losing events in between the polling intervals. Overall, your change looks good. Thanks for working on it. |
No description provided.