<div dir="ltr"><font face="monospace, monospace">Hello honza, thanks for the response !</font><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">With state sync, I simply mean that 'k-1' messages were delivered to N1, N2 and N3 and they have applied these messages to change their program state.</font></div><div><font face="monospace, monospace">N1.state = apply(m(k-1);</font></div><div><font face="monospace, monospace">N2.state = apply(m(k-1);</font></div><div><font face="monospace, monospace">N3.state = apply(m(k-1);</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">The document you shared cleared many doubts. However I still need one clarification.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">According to the document:</font></div><div><font face="monospace, monospace">"The configuration change messages warn the application that a membership change has occurred, so that the application program can take appropriate action based on the membership change. Extended virtual synchrony guarantees a consistent order of messages delivery across a partition, which is essential if the application program are to be able to reconcile their states following repair of a failed processor or reemerging of the partitioned network."</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">I just want to know that this property is not something related to CPG_TYPE_SAFE, which is still not implemented.</font></div><div><font face="monospace, monospace">Please consider this scenario:</font></div><div><font face="monospace, monospace">0. N1, N2 and N3 has received the message m(k-1).</font></div><div><font face="monospace, monospace">1. N1 mcast(CPG_TYPE_AGREED) m(k) message.</font></div><div><span style="font-family:monospace,monospace">2. As it is not CPG_TYPE_SAFE, </span><span style="font-family:monospace,monospace">m(k) delievered to N1 but was not yet delivered to N2 and N3.</span></div><div><font face="monospace, monospace">3. Network partition separate N1 from N2 and N3. N2 and N3 can never see m(k).</font></div><div><font face="monospace, monospace">4. Configuration change message is now delivered to N1, N2 and N3.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Here, N1 will change its state to N1.state = apply(m(k), thinking all in the current configuration has received the message. </font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">According to your reply it looks like N1 will not receive m(k). So this is what each node will see:</font></div><div><font face="monospace, monospace">N1 will see: m(k-1) -> C1 (config change)</font></div><div><font face="monospace, monospace">N2 will see: m(k-1) -> C1 (config change)</font></div><div><font face="monospace, monospace">N3 will see: m(k-1) -> C1 (config change)</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Message m(k) will be discarded, and will not be delivered to N1 even if it was sent by N1 before the network partition.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">This is the expected behavior with </font><span style="font-family:monospace,monospace">CPG_TYPE_AGREED?</span></div><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">Regards,</span></div><div><span style="font-family:monospace,monospace">Satish</span></div><div><span style="font-family:monospace,monospace"><br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 6, 2016 at 4:15 PM, Jan Friesse <span dir="ltr"><<a href="mailto:jfriesse@redhat.com" target="_blank">jfriesse@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Hello,<br>
<br>
Virtual Synchrony Property - messages are delivered in agreed order and<br>
configuration changes are delivered in agreed order relative to message.<br>
<br>
What happen to this property when network is partitioned the cluster into<br>
two. Consider following scenario (which I took from one of the<br>
previous query by Andrei Elkin):<br>
<br>
* N1, N2 and N3 are in state sync with m(k-1) messages are delivered.<br>
</blockquote>
<br></span>
What exactly you mean by "state sync"?<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
* N1 sends m(k) and just now network partition N1 node from N2 and N3.<br>
<br>
Does CPG_TYPE_AGREED guarantee that virtual synchrony is held?<br>
</blockquote>
<br></span>
Yes it does (actually higher level of VS called EVS)<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
When property is held, configuration change message C1 is guaranteed to<br>
delivered before m(k) to N1.<br>
N1 will see: m(k-1) C1 m(k)<br>
N2 and N3 will see: m(k-1) C1<br>
<br>
But if this property is violated:<br>
N1 will see: m(k-1) m(k) C1<br>
N2 and N3 will see: m(k-1) C1<br>
<br>
Violation will screw any user application running on the cluster.<br>
<br>
Could someone please explain what is the behavior of Corosync in this<br>
scenario with CPG_TYPE_AGREED ordering.<br>
</blockquote>
<br></span>
For description how exactly totem synchronization works take a look to <a href="http://corosync.github.com/corosync/doc/DAAgarwal.thesis.ps.gz" rel="noreferrer" target="_blank">http://corosync.github.com/corosync/doc/DAAgarwal.thesis.ps.gz</a><br>
<br>
After totem is synchronized, there is another level of synchronization of services (not described in above doc). All services synchronize in very similar way, so you can take a look to CPG as example. Basically only state held by CPG is connected clients. So every node sends it's connected clients list to every other node. If sync is aborted (change of membership), it's restarted. These sync messages has priority over user messages (actually it's not possible to send messages during sync). User app can be sure that message was delivered only after it gets it's own message. Also app gets configuration change message so it knows, who got the message.<br>
<br>
Regards,<br>
Honza<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Satish<br>
<br>
<br>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
<br>
</blockquote>
<br>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</blockquote></div><br></div></div>