<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 02:54 PM, Radoslaw
Gruchalski wrote:<br>
</div>
<blockquote
cite="mid:CAJTjOQEQ253mOzOvaU5eU-L-hm82kJHZPPs6CgZ-7nV4cCo-eg@mail.gmail.com"
type="cite">
<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>
</blockquote>
Both cpg and pg2 rely on Erlang node monitoring provided by
distributed Erlang. Distributed Erlang is using the node heartbeat
configured with net_ticktime (<a class="moz-txt-link-freetext" href="http://erlang.org/doc/man/kernel_app.html">http://erlang.org/doc/man/kernel_app.html</a>).<br>
<blockquote
cite="mid:CAJTjOQEQ253mOzOvaU5eU-L-hm82kJHZPPs6CgZ-7nV4cCo-eg@mail.gmail.com"
type="cite">
<div dir="ltr">
<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 moz-do-not-send="true"
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
style="font-size:8pt" size="1"><span
style="font-style:normal"><b>Confidentiality:</b></span></font></font></font><font
color="#999999"><font face="Helvetica, sans-serif"><font
style="font-size:8pt" size="1"><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 moz-do-not-send="true"
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_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>
_______________________________________________<br>
erlang-questions mailing list<br>
<a moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org"
target="_blank">erlang-questions@erlang.org</a><br>
<a moz-do-not-send="true"
href="http://erlang.org/mailman/listinfo/erlang-questions"
target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>