Fullstop000
Fullstop000
@Hoverbear Yes, though I still want a benchmark over the channel-based cluster (maybe create a specialized harness for this?). And I realize that by the no overhead approach the whole...
Maybe we can just add `utils::limit_size(after_batched_msg.entries, self.max_msg_size)`. But we still get some extra cost from the `self.raft_log.entries()`.
Can you provide a more specific scenario for this feature? I think the MVCC style of reading could be more easily achieved out of the raft lib.
> It seems that now the follower read have to wait the follower keep latest with leader. Is the key point that we don't have a mapping like `index` =>...
Does #318 need to be merged first?
I just want to make the implementation stay consistent with `resotre_snapmeta` :). Feel free to close this.
@Hoverbear Can I try to implement a simple benchmark case for raw node proposing like https://github.com/etcd-io/etcd/blob/master/raft/node_bench_test.go ? This could be useful in a lot of situations.
If a node has joined in a cluster, you should just restart it without sending re-join msg. @Licenser
The node 2 and node 3 both panicked directly when I tried to reproduce the scenario in step 8: ``` Nov 01 00:24:56.636 ERRO e: The node 3 already exists...