<div dir="ltr"><div>Ulf, I need to up the priority of replacing gen_leader with your distributed locker.  I've certainly experienced some of the problems Christopher is talking about with gen_leader.<br><br></div>Christopher, great blog posts!  I need to go read some more, my first skimming wasn't enough...<br>
<br>-G<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 12:03 PM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 13 Nov 2013, at 20:27, Christopher Meiklejohn <<a href="mailto:cmeiklejohn@basho.com">cmeiklejohn@basho.com</a>> wrote:<br>
<br>
> 1. It’s reliance on gen_leader, and it’s problems with deadlocks, dynamic membership and network partitions.<br>
> 2. gproc’s resolution strategies for conflicting values after resolution of a network partition.<br>
<br>
</div>This is partly why I prefer the locks_leader version.<br>
<br>
The locks_leader actually *only* supports dynamic membership right now, but could evolve to support a more restrictive strategy. It also has some added facilities for addressing the other candidates from within the elected() callback, in order to merge inside a protected state. This is used in the gdict example, but not in gproc.<br>

<br>
Gproc doesn’t use it, since its dictionary isn’t transaction-consistent anyway.<br>
The deconflict method in gproc is selected at registration time. Currently, three methods<br>
are supported: exit_all, smallest_pid and largest_pid. It would be easy to add more, as<br>
long as they are well-defined and safe in a distributed setting. Global has one alternative<br>
where a user-provided function is called with the conflicting entries, and one entry is<br>
expected to be picked.<br>
<br>
I’ll gladly take suggestions here.<br>
<br>
BR,<br>
Ulf<br>
<br>
BTW, in locks_leader, I’m currently experimenting with additions for supporting the<br>
RAFT consensus algorithm. First, I added leader surrender, which seems to work<br>
well. I’ve also added an ‘info’ attribute in lock entries, which could be used to select<br>
the ‘best’ leader candidate (which would be done in the elected() callback, possibly<br>
leading to a surrender to that candidate.<br>
<br>
Of course, one doesn’t have to use locks_leader for a RAFT implementation<br>
(I’m aware of rafter), but it was a fun challenge to see if it could be done.<br>
<div class="HOEnZb"><div class="h5"><br>
Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.<br>
<a href="http://feuerlabs.com" target="_blank">http://feuerlabs.com</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>