Well the follower would get a full SNAP in that case, leaving a weird log state. Would be useful though to list the series of events that would cause such a scenario within the bounds of otherwise normal operating behavior (ie, all machine logs were created by members of this cluster during the last round of healthy operation). Should this ever happen at all?
C ----- Original Message ----- From: Vishal Kher <vishalm...@gmail.com> To: dev@zookeeper.apache.org <dev@zookeeper.apache.org> Sent: Mon Jun 06 13:11:05 2011 Subject: Potential bug with Leader.TRUNC? Hi, In LearnerHandler, the code that sends TRUNC to the follower is shown below: * if (proposals.size() != 0) { * if ((maxCommittedLog >= peerLastZxid) && (minCommittedLog <= peerLastZxid)) { packetToSend = Leader.DIFF; zxidToSend = maxCommittedLog; for (Proposal propose: proposals) { if (propose.packet.getZxid() > peerLastZxid) { queuePacket(propose.packet); QuorumPacket qcommit = new QuorumPacket(Leader.COMMIT, propose.packet.getZxid(), null, null); queuePacket(qcommit); } } } else if (peerLastZxid > maxCommittedLog) { * packetToSend = Leader.TRUNC;* zxidToSend = maxCommittedLog; updates = zxidToSend; } } else { // just let the state transfer happen } Why does it send a TRUNC only when the size of proposal's in memory is != 0? What if after a new leader election, the transaction log of the leader is empty (i.e., no proposals). If an old leader tries to join and has higher transaction ID recorded in its transaction log, then it won't truncate its transaction log. I think with the right combination of zxid of the transaction log and snapshot we might see this problem. Am I misreading the code? Thanks, -Vishal