[erlang-questions] ETS tables and pubsub

[Ulf Wiger]

Of course, locks_leader has no obvious deficiencies. ;-)

BR,
Ulf W

On 13 Nov 2013, at 21:19, Garret Smith <garret.smith@REDACTED> wrote:

> 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.
> 
> Christopher, great blog posts!  I need to go read some more, my first skimming wasn't enough...
> 
> -G
> 
> 
> On Wed, Nov 13, 2013 at 12:03 PM, Ulf Wiger <ulf@REDACTED> wrote:
> 
> On 13 Nov 2013, at 20:27, Christopher Meiklejohn <cmeiklejohn@REDACTED> wrote:
> 
> > 1. It’s reliance on gen_leader, and it’s problems with deadlocks, dynamic membership and network partitions.
> > 2. gproc’s resolution strategies for conflicting values after resolution of a network partition.
> 
> This is partly why I prefer the locks_leader version.
> 
> 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.
> 
> Gproc doesn’t use it, since its dictionary isn’t transaction-consistent anyway.
> The deconflict method in gproc is selected at registration time. Currently, three methods
> are supported: exit_all, smallest_pid and largest_pid. It would be easy to add more, as
> long as they are well-defined and safe in a distributed setting. Global has one alternative
> where a user-provided function is called with the conflicting entries, and one entry is
> expected to be picked.
> 
> I’ll gladly take suggestions here.
> 
> BR,
> Ulf
> 
> BTW, in locks_leader, I’m currently experimenting with additions for supporting the
> RAFT consensus algorithm. First, I added leader surrender, which seems to work
> well. I’ve also added an ‘info’ attribute in lock entries, which could be used to select
> the ‘best’ leader candidate (which would be done in the elected() callback, possibly
> leading to a surrender to that candidate.
> 
> Of course, one doesn’t have to use locks_leader for a RAFT implementation
> (I’m aware of rafter), but it was a fun challenge to see if it could be done.
> 
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
> 
> 
> 
> 

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131113/b4463455/attachment.htm>