Releases: dgkimura/paxos
Releases · dgkimura/paxos
1.0.9
1.0.7
Use LRU set in acceptor to track accepted decrees Issue is that without using an LRU set the memory used to keep track of accepted decree results would grow indefinitely. This change mantains an LRU set to prevent indifinite memory usage and continue to track accepted decrees.
1.0.6
Fix missing decrees Issue is that previously accepted decree from past rounds would later be be handled as rejected decrees in subsequent rounds. This leads to confusion when calculating quorum in the rejection handler. This commit fixes this by maintaining a map of previous accepted decrees of the acceptor.
1.0.5
Fix absentee ballot count with decree contention Issue is that absentee ballot count should contain a single entry for each root decree. Decree number is actually meaningless in this context. As such it should not be used in the hash algorithm. A simple solution is to set decree number equal to root number.
1.0.4
Add period attempt to flush stuck decrees. Issue is that it is possible for a decree to become stuck if messages are dropped at inopportune times. For example, if a proposer sends out a prepare, but all the messages are lost then the decree can be come stuck. In order to become unstuck the proposer must re-send the prepare or another decree has to be accepted from another replica and retrigger a new round of paxos. This change allows the first scenario to take place so that the replica can unstick itself.
1.0.3
1.0.2
Filter prepare response on reject-tie decrees. This commmit adds additional constraits to logic for resending prepare messages during decree contention. It limits the prepare message response to trigger a single time for a given decree, regardless of who sent the message. This prevents growth of messages sent by preventing multiple messages in response to a duplicate reject-tie message from separate replicas. Fixes #6