[
https://issues.apache.org/jira/browse/ZOOKEEPER-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vishal K updated ZOOKEEPER-1081:
--------------------------------
Attachment: sample.diff
Hi Ben,
I have attached the diff that I used to repro the bug.
I inserted a failure in ProposalRequestProcessor.java. Everytime I read file
/etc/zookeeper/debug.property. I check if the debug property is set. If it is,
then I fail (I did shutdown -h to avoid some timing issues specific to our
application) the leader after call to syncProcessor.processRequest(request).
This ensures that the transaction is logged but not sent to followers. Then,
when we restart the old leader we can check if it still has the old data.
Do you think this helps? I think we need to start injecting faults in the code
itself. So having a framwork that would do something similar to the attached
diff would be useful.
> modify leader/follower code to correctly deal with new leader
> -------------------------------------------------------------
>
> Key: ZOOKEEPER-1081
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1081
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: server
> Reporter: Benjamin Reed
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-1081.patch, sample.diff
>
>
> the leader and follower code need to be modified to correctly handle and log
> epoch changes
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
