The confusing code in example

[chen-zhuohan]

the code in examples/five_mem_node/main.rs:281

    let mut handle_committed_entries =
        |rn: &mut RawNode<MemStorage>, committed_entries: Vec<Entry>| {
            for entry in committed_entries {
                if entry.data.is_empty() {
                    // From new elected leaders.
                   // ----------------------- 1 -----------------------
                    continue;    
                }
                if let EntryType::EntryConfChange = entry.get_entry_type() {
                    // For conf change messages, make them effective.
                    let mut cc = ConfChange::default();
                    cc.merge_from_bytes(&entry.data).unwrap();
                    let cs = rn.apply_conf_change(&cc).unwrap();
                    store.wl().set_conf_state(cs);
                } else {
                    // For normal proposals, extract the key-value pair and then
                    // insert them into the kv engine.
                    let data = str::from_utf8(&entry.data).unwrap();
                    let reg = Regex::new("put ([0-9]+) (.+)").unwrap();
                    if let Some(caps) = reg.captures(&data) {
                        kv_pairs.insert(caps[1].parse().unwrap(), caps[2].to_string());
                    }
                }
                if rn.raft.state == StateRole::Leader {
                    // The leader should response to the clients, tell them if their proposals
                    // succeeded or not.
                    let proposal = proposals.lock().unwrap().pop_front().unwrap();
                    // ----------------------- 2 -----------------------
                    proposal.propose_success.send(true).unwrap();
                }
            }
        };

1. in --1--, skipping one loop. And in --2--, just pop proposal from proposals. Could it make some proposals not to reply?
2. Is it enough to send(true) directly in --2--?

[BusyJay]

Could it make some proposal not reply?

The example won't propose any empty proposals. In practice, you may want to use its index and term to check whether it's a proposal proposed by raft library or yourself.

Is it enough to send(true) directly in --2--

It's just an example to show how to handle committed logs. What is needed to be done depends on application logic. What raft needs is the apply progress of conf change.

[chen-zhuohan]

The first point, when should I care about index and term? Can you give more tips?

The second point, I means is there any condition to do send(false)?

[chen-zhuohan]

Another question... The newest version code can not pass five_mem_node example:

Here is the latest logs:

Dec 29 19:39:01.895 INFO Propose 100 proposals success!
Dec 29 19:39:01.895 DEBG Sending from 2 to 1, msg: msg_type: MsgAppendResponse to: 1 index: 106 commit: 106, to: 1, from: 2, raft_id: 2, tag: peer_2
Dec 29 19:39:01.896 DEBG Sending from 4 to 1, msg: msg_type: MsgAppendResponse to: 1 index: 106 commit: 106, to: 1, from: 4, raft_id: 4, tag: peer_4
Dec 29 19:39:01.901 DEBG Sending from 5 to 1, msg: msg_type: MsgAppendResponse to: 1 index: 106 commit: 106, to: 1, from: 5, raft_id: 5, tag: peer_5
Dec 29 19:39:01.903 DEBG Sending from 3 to 1, msg: msg_type: MsgAppendResponse to: 1 index: 106 commit: 106, to: 1, from: 3, raft_id: 3, tag: peer_3
Dec 29 19:39:01.904 DEBG Sending from 5 to 1, msg: msg_type: MsgHeartbeatResponse to: 1 commit: 106, to: 1, from: 5, raft_id: 5, tag: peer_5
Dec 29 19:39:01.905 DEBG Sending from 2 to 1, msg: msg_type: MsgHeartbeatResponse to: 1 commit: 106, to: 1, from: 2, raft_id: 2, tag: peer_2
Dec 29 19:39:01.907 DEBG Sending from 4 to 1, msg: msg_type: MsgHeartbeatResponse to: 1 commit: 106, to: 1, from: 4, raft_id: 4, tag: peer_4
Dec 29 19:39:01.908 DEBG Sending from 3 to 1, msg: msg_type: MsgHeartbeatResponse to: 1 commit: 106, to: 1, from: 3, raft_id: 3, tag: peer_3
Dec 29 19:39:01.910 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.910 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.910 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.911 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.911 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.912 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.912 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.912 ERRO send raft message to 1 fail, let Raft retry it

And the version v0.4.3, it doesn't have example five_mem_node...

git clone https://github.com/tikv/raft-rs.git -b v0.4.3

[BanBuDu0]

Another question... The newest version code can not pass five_mem_node example:

Here is the latest logs:

Dec 29 19:39:01.895 INFO Propose 100 proposals success!
Dec 29 19:39:01.895 DEBG Sending from 2 to 1, msg: msg_type: MsgAppendResponse to: 1 index: 106 commit: 106, to: 1, from: 2, raft_id: 2, tag: peer_2
Dec 29 19:39:01.896 DEBG Sending from 4 to 1, msg: msg_type: MsgAppendResponse to: 1 index: 106 commit: 106, to: 1, from: 4, raft_id: 4, tag: peer_4
Dec 29 19:39:01.901 DEBG Sending from 5 to 1, msg: msg_type: MsgAppendResponse to: 1 index: 106 commit: 106, to: 1, from: 5, raft_id: 5, tag: peer_5
Dec 29 19:39:01.903 DEBG Sending from 3 to 1, msg: msg_type: MsgAppendResponse to: 1 index: 106 commit: 106, to: 1, from: 3, raft_id: 3, tag: peer_3
Dec 29 19:39:01.904 DEBG Sending from 5 to 1, msg: msg_type: MsgHeartbeatResponse to: 1 commit: 106, to: 1, from: 5, raft_id: 5, tag: peer_5
Dec 29 19:39:01.905 DEBG Sending from 2 to 1, msg: msg_type: MsgHeartbeatResponse to: 1 commit: 106, to: 1, from: 2, raft_id: 2, tag: peer_2
Dec 29 19:39:01.907 DEBG Sending from 4 to 1, msg: msg_type: MsgHeartbeatResponse to: 1 commit: 106, to: 1, from: 4, raft_id: 4, tag: peer_4
Dec 29 19:39:01.908 DEBG Sending from 3 to 1, msg: msg_type: MsgHeartbeatResponse to: 1 commit: 106, to: 1, from: 3, raft_id: 3, tag: peer_3
Dec 29 19:39:01.910 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.910 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.910 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.911 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.911 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.912 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.912 ERRO send raft message to 1 fail, let Raft retry it
Dec 29 19:39:01.912 ERRO send raft message to 1 fail, let Raft retry it

And the version v0.4.3, it doesn't have example five_mem_node...

git clone https://github.com/tikv/raft-rs.git -b v0.4.3

I can run five_mem_node example bug freely with the lastest master branch. After Propose 100 proposals success!, there is a Terminate Signal send to the stop channel, and all raft thread will exit successfully. However I got the same problem before, and I think the reason maybe is that I leave the scope of the receive channel and the owership is end, and then raft communicate failed