<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/08/2015 12:59 PM, Roberto
Ostinelli wrote:<br>
</div>
<blockquote
cite="mid:32C204D4-9CE1-4D73-AC4F-43AF9808943A@widetag.com"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>Hello Michael,</div>
<div>I know of those but I've left them out as I do not need group
mechanisms: I'm not interested in broadcasting messages to
multiple devices. Just a 1-to-1 messaging.</div>
</blockquote>
That usage of pg2 and cpg just means that you would only have a
single pid in a group. It might seem a bit different, but I don't
think there is a better alternative.<br>
<blockquote
cite="mid:32C204D4-9CE1-4D73-AC4F-43AF9808943A@widetag.com"
type="cite">
<div><br>
</div>
<div>Is there any reason why using these process groups be
beneficial in my use case?</div>
</blockquote>
The main reason is that you avoid the need to resolve state
conflicts when global state gets merged after a netsplit. With pg2
and cpg, all the state relevant to the local node is stored locally
and remote state gets merged as nodes are added. When a node dies,
its pids are removed, as expected, but there is no need for
centralized global state.<br>
<blockquote
cite="mid:32C204D4-9CE1-4D73-AC4F-43AF9808943A@widetag.com"
type="cite">
<div><br>
</div>
<div>Thank you for your input,</div>
<div>r.<br>
<br>
<br>
</div>
<div><br>
On 08/feb/2015, at 21:51, Michael Truog <<a
moz-do-not-send="true" href="mailto:mjtruog@gmail.com">mjtruog@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 02/08/2015 11:56 AM, Roberto
Ostinelli wrote:<br>
</div>
<blockquote
cite="mid:CAM5fRyo2A4wDVHTe8BebV0arSr=DxFm-doo=viffpHLqJKdhhg@mail.gmail.com"
type="cite">
<div dir="ltr">Dear list,
<div>I have 3 interconnected nodes to which various
devices connect to.</div>
<div>Once a device connects to one of those nodes, the
related TCP socket events are handled by a device_loop
process on the node that it originally connected to.<br>
</div>
<div><br>
</div>
<div>Every device is identified via its id (a binary). I
need to enable communication from one device to the
other based on these ids, even within different nodes. I
have around 150k device processes per node (so up to
500k in total).</div>
<div><br>
</div>
<div>So, I basically need a global process registry. Not
new, but haven't used one in a while now.</div>
<div><br>
</div>
<div>As far as I can tell, my main options to send
messages from one device process to the other based on
their id are the erlang <font face="monospace,
monospace">global</font> module, ulf's <font
face="monospace, monospace">gproc</font><font
face="arial, helvetica, sans-serif">, or implement a
custom solution based on, for instance, mnesia in ram
only.</font></div>
<div><br>
</div>
<div><br>
<div>I was first thinking of leaning towards using the
erlang <font face="monospace, monospace">global</font>
module, since <font face="monospace, monospace">register_name/2,3</font>
now also allows general terms to be used as Name. The
advantages I see:</div>
</div>
<div>
<ul>
<li>It is a simple built-in mechanism.</li>
<li>If a node goes down, the global names registered
on that node are unregistered automatically.</li>
<li>If a new node is added, the global names
registered are propagated automatically.</li>
</ul>
<div>The cons:</div>
</div>
<div>
<ul>
<li>I always feel that process registration should be
used to identify long-running services.</li>
<li>I don't know if 500k is an acceptable number (i.e.
if the <font face="monospace, monospace">global</font>
module is made to support my use case).</li>
</ul>
<div><br>
</div>
<div>I also looked into <font face="monospace,
monospace">gproc</font>. The advantages I see:</div>
<div>
<ul>
<li>Actively maintained, it seems to have been built
for my use case.</li>
</ul>
<div>The cons:<br>
</div>
</div>
<div>
<ul>
<li>For the distributed part it relies on <font
face="monospace, monospace">gen_leader</font>.
I've heard too many horror stories on <span
style="font-family:monospace,monospace">gen_leader</span><font
face="arial, helvetica, sans-serif">. Maybe
that's not a thing anymore.</font></li>
<li><font face="arial, helvetica, sans-serif">Not
sure what happens if a node goes down / a new
node is added.</font></li>
</ul>
<div><font face="arial, helvetica, sans-serif"><br>
</font></div>
</div>
</div>
<div><font face="arial, helvetica, sans-serif">I've
considered a custom solution based on mnesia
distributed ram-only tables that would store the pids
of the device loops based on their binary id.</font>The
advantages I see:</div>
<div>
<ul>
<li>Mnesia will take care of distributing, handling
down events, etc.</li>
</ul>
<div>The cons:<br>
</div>
</div>
<div>
<ul>
<li>I need to reinvent the wheel and ensure that when
a node goes down, all the device entries in the
distributed mnesia tables related to that node are
removed.</li>
</ul>
<div><br>
</div>
</div>
<div><br>
</div>
<div>Has someone recently implemented a distributed
process registry and can shed some light for me?</div>
<div><br>
</div>
<div>Thank you in advance for your advice ^^_</div>
<div>r.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<tt>You are missing a few options:<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.erlang.org/doc/man/pg2.html">http://www.erlang.org/doc/man/pg2.html</a><br>
* Any term can be used for a name<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/okeuday/cpg/">https://github.com/okeuday/cpg/</a><br>
* By default uses string (list of integer) names, but can be
changed with group_storage application env setting (e.g., to
dict)<br>
* Supports any number of scopes, which are atoms that are
used as locally registered cpg process identifiers (pg2 only
supports the single global scope stored in ETS)<br>
* Supports the via syntax, like gproc does, with variations
that allow pools to be created (<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://github.com/okeuday/cpg/blob/master/test/cpg_test.erl#L83-L104">https://github.com/okeuday/cpg/blob/master/test/cpg_test.erl#L83-L104</a>)<br>
<br>
Both pg2 and cpg allow you to avoid centralized global state
(the state used in gproc, locks_leader, mnesia, global) so
that netsplits do not require an arbitrary process to
resolve state conflicts. That is very important for
reliability.<br>
<br>
<br>
</tt> </div>
</blockquote>
</blockquote>
<br>
</body>
</html>