<div dir="ltr"><div><div><div>I know Ulf has been doing some work on gproc to make it handle netsplits better.  I keep meaning to try it out...<br><br><a href="http://erlang.org/pipermail/erlang-questions/2013-June/074345.html">http://erlang.org/pipermail/erlang-questions/2013-June/074345.html</a><br>
<br></div>For me, I'm using a combination of gen_leader and local-only gproc.  My application has partitioned graphs of data flow & process interaction, so I can use gen_leader to manage moving entire graphs between nodes and local gproc for processes within a graph to find each other.<br>
<br></div>A generic process registry that handles netsplit and nodes entering and leaving the cluster is a Very Hard Problem(TM).  You'd still have to write some bits yourself, like how to merge registries after a netsplit.  That's why a lot of application-specific solutions (like mine) exist to exploit the inherent properties of the problem.<br>
<br></div>-Garret Smith<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 9:50 AM, Christopher Meiklejohn <span dir="ltr"><<a href="mailto:cmeiklejohn@basho.com" target="_blank">cmeiklejohn@basho.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">On Wednesday, November 13, 2013 at 12:19 AM, Barco You wrote:<br>
> Why don't you use gproc?<br>
<br>
</div>Last time I checked, gproc isn’t super reliable under failure conditions in global distribution mode.<br>
<br>
Garret and Ulf have discussed it on erlang-questions [1], section 10 of Ulf’s Erlang Workshop paper [2] covers quite a bit about it, and I’ve also written about it [3].<br>
<br>
[1] <a href="http://erlang.org/pipermail/erlang-questions/2012-July/067749.html" target="_blank">http://erlang.org/pipermail/erlang-questions/2012-July/067749.html</a><br>
[2] <a href="http://svn.ulf.wiger.net/gproc/doc/erlang07-wiger.pdf" target="_blank">http://svn.ulf.wiger.net/gproc/doc/erlang07-wiger.pdf</a><br>
[3] <a href="http://christophermeiklejohn.com/erlang/2013/06/05/erlang-gproc-failure-semantics.html" target="_blank">http://christophermeiklejohn.com/erlang/2013/06/05/erlang-gproc-failure-semantics.html</a><br>
<br>
- Chris<br>
<div><div class="h5"><br>
> On Wed, Nov 13, 2013 at 2:38 AM, akonsu <<a href="mailto:akonsu@gmail.com">akonsu@gmail.com</a> (mailto:<a href="mailto:akonsu@gmail.com">akonsu@gmail.com</a>)> wrote:<br>
> > I have a pubsub system which has a single publisher process that maintains all its subscriber processes' Pid's in an ETS table.<br>
> ><br>
> > The publisher monitors its subscribers and when the publisher receives DOWN message, it removes the subscriber Pid from the table.<br>
> ><br>
> > The table entries are tuples of the form {MonitorRef, SubscriberPid}, and the MonitorRef is used as the key.<br>
> ><br>
> > Now I would like to make sure that if the publisher dies, and gets restarted by its supervisor, the subscriber table is preserved. So I created a process that creates the ETS table, sets the table's heir to self(), and then gives away the table to the publisher.<br>

> ><br>
> > The problem is that I do not know how to handle transfer of the table from the heir to the publisher:<br>
> ><br>
> > when publisher receives the table, the table contains a list of tuples {MonitorRef, SubscriberPid}, but the MonitorRefs were created by the previous publisher instance, so when the new publisher receives ETS_TRANSFER it needs to monitor all these SubscriberPids again.<br>

> ><br>
> > what is the best way to do it? Loop over all ETS entries, attach a monitor to each and reenter the new MonitorRefs into the table? This might be slow, no? Maybe my architecture can be improved? Any advice?<br>
> ><br>
> > thanks<br>
> > Konstantin<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > erlang-questions mailing list<br>
</div></div>> > <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a> (mailto:<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>)<br>
> > <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a> (mailto:<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>)<br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>