<div dir="ltr"><div>Michael,</div><div><br></div>Out of curiosity, do you have any occasional pings? How do you know when the netsplit happened? You rely on erlang facilities only?<div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Kind regards,<div><br><div>Radek Gruchalski</div></div><div><a href="mailto:radek@gruchalski.com" target="_blank">radek@gruchalski.com</a></div><div><p style="margin-bottom:0cm"><font color="#999999"><font face="Helvetica, sans-serif"><font size="1" style="font-size:8pt"><span style="font-style:normal"><b>Confidentiality:</b></span></font></font></font><font color="#999999"><font face="Helvetica, sans-serif"><font size="1" style="font-size:8pt"><span style="font-style:normal"><br>This
communication is intended for the above-named person and may be
confidential and/or legally privileged.<br>If it has come to you in
error you must take no action based on it, nor must you copy or show
it to anyone; please delete/destroy and inform the sender
immediately.</span></font></font></font></p></div></div></div></div>
<br><div class="gmail_quote">On Sun, Feb 8, 2015 at 11:14 PM, Michael Truog <span dir="ltr"><<a href="mailto:mjtruog@gmail.com" target="_blank">mjtruog@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/08/2015 01:41 PM, Loïc Hoguin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 02/08/2015 10:10 PM, Michael Truog wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is there any reason why using these process groups be beneficial in my<br>
use case?<br>
</blockquote>
The main reason is that you avoid the need to resolve state conflicts<br>
when global state gets merged after a netsplit.  With pg2 and cpg, all<br>
the state relevant to the local node is stored locally and remote state<br>
gets merged as nodes are added.  When a node dies, its pids are removed,<br>
as expected, but there is no need for centralized global state.<br>
</blockquote>
<br>
I'm curious.<br>
<br>
When a node connects it sends its state to all the nodes it connects to? And when a process group gets registered it sends this info to all the nodes?<br>
<br>
</blockquote>
Yes, basically.  Node connections are monitored and when a new node appears (after a nodesplit or a new node connection) the cpg scope process sends its state to the new node's cpg scope process.  When cpg is first started, it also makes sure to let the other nodes cpg processes know it exists, so they will send their state to it.  The state is merged, so that remote pids are stored and monitored.<br>
<br>
When a cpg process is added to a group, it is added locally, and the addition is sent asynchronously to remote nodes (if they don't receive it, a netsplit or reliability problem is happening anyway, so that will get resolved as described above).  This functions like pg2, except that pg2 only uses a single scope and makes the addition synchronous, relying on the global module for a global transaction lock.  The cpg approach avoids a global lock by requiring that the cpg scope process be locally consistent (as if the single Erlang process functions as a mutex lock), which means that the cpg process is only dealing with local node pids (you can not add remote pids to the local cpg process).  There is a macro to get the pg2 approach in cpg (undefine GROUP_NAME_WITH_LOCAL_PIDS_<u></u>ONLY), but it is better to use that restriction to avoid a dependency on the global module.  The cpg return values are the same as pg2, so you can switch between them if you aren't using cpg specific features, like scopes.<br>
<br>
cpg doesn't require a group be created before the join, but pg2 does.  So cpg usage can rely only upon join/leave for group membership.<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</blockquote></div><br></div></div>