But C1 is *guaranteed *to deliver *before *m(k)? No case where C1 is delivered after m(k)?
Regards, Satish On Mon, Jun 6, 2016 at 8:10 PM, Jan Friesse <jfrie...@redhat.com> wrote: > satish kumar napsal(a): > > Hello honza, thanks for the response ! >> >> 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. >> N1.state = apply(m(k-1); >> N2.state = apply(m(k-1); >> N3.state = apply(m(k-1); >> >> The document you shared cleared many doubts. However I still need one >> clarification. >> >> According to the document: >> "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." >> >> I just want to know that this property is not something related to >> CPG_TYPE_SAFE, which is still not implemented. >> Please consider this scenario: >> 0. N1, N2 and N3 has received the message m(k-1). >> 1. N1 mcast(CPG_TYPE_AGREED) m(k) message. >> 2. As it is not CPG_TYPE_SAFE, m(k) delievered to N1 but was not yet >> delivered to N2 and N3. >> 3. Network partition separate N1 from N2 and N3. N2 and N3 can never see >> m(k). >> 4. Configuration change message is now delivered to N1, N2 and N3. >> >> Here, N1 will change its state to N1.state = apply(m(k), thinking all in >> the current configuration has received the message. >> >> According to your reply it looks like N1 will not receive m(k). So this is >> what each node will see: >> N1 will see: m(k-1) -> C1 (config change) >> N2 will see: m(k-1) -> C1 (config change) >> N3 will see: m(k-1) -> C1 (config change) >> > > For N2 and N3, it's not same C1. So let's call it C2. Because C1 for N1 is > (N2 and N3 left) and C2 for N2 and N3 is (N1 left). > > > >> Message m(k) will be discarded, and will not be delivered to N1 even if it >> was sent by N1 before the network partition. >> > > No. m(k) will be delivered to app running on N1. So N1 will see m(k-1), > C1, m(k). So application exactly knows which node got message m(k). > > Regards, > Honza > > > >> This is the expected behavior with CPG_TYPE_AGREED? >> >> Regards, >> Satish >> >> >> On Mon, Jun 6, 2016 at 4:15 PM, Jan Friesse <jfrie...@redhat.com> wrote: >> >> Hi, >>> >>> Hello, >>> >>>> >>>> Virtual Synchrony Property - messages are delivered in agreed order and >>>> configuration changes are delivered in agreed order relative to message. >>>> >>>> What happen to this property when network is partitioned the cluster >>>> into >>>> two. Consider following scenario (which I took from one of the >>>> previous query by Andrei Elkin): >>>> >>>> * N1, N2 and N3 are in state sync with m(k-1) messages are delivered. >>>> >>>> >>> What exactly you mean by "state sync"? >>> >>> * N1 sends m(k) and just now network partition N1 node from N2 and N3. >>> >>>> >>>> Does CPG_TYPE_AGREED guarantee that virtual synchrony is held? >>>> >>>> >>> Yes it does (actually higher level of VS called EVS) >>> >>> >>> When property is held, configuration change message C1 is guaranteed to >>>> delivered before m(k) to N1. >>>> N1 will see: m(k-1) C1 m(k) >>>> N2 and N3 will see: m(k-1) C1 >>>> >>>> But if this property is violated: >>>> N1 will see: m(k-1) m(k) C1 >>>> N2 and N3 will see: m(k-1) C1 >>>> >>>> Violation will screw any user application running on the cluster. >>>> >>>> Could someone please explain what is the behavior of Corosync in this >>>> scenario with CPG_TYPE_AGREED ordering. >>>> >>>> >>> For description how exactly totem synchronization works take a look to >>> http://corosync.github.com/corosync/doc/DAAgarwal.thesis.ps.gz >>> >>> 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. >>> >>> Regards, >>> Honza >>> >>> >>> Regards, >>>> Satish >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list: Users@clusterlabs.org >>>> http://clusterlabs.org/mailman/listinfo/users >>>> >>>> Project Home: http://www.clusterlabs.org >>>> Getting started: >>>> http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>> Bugs: http://bugs.clusterlabs.org >>>> >>>> >>>> >>> _______________________________________________ >>> Users mailing list: Users@clusterlabs.org >>> http://clusterlabs.org/mailman/listinfo/users >>> >>> Project Home: http://www.clusterlabs.org >>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>> Bugs: http://bugs.clusterlabs.org >>> >>> >> >> >> _______________________________________________ >> Users mailing list: Users@clusterlabs.org >> http://clusterlabs.org/mailman/listinfo/users >> >> Project Home: http://www.clusterlabs.org >> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >> Bugs: http://bugs.clusterlabs.org >> >> > > _______________________________________________ > Users mailing list: Users@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org >
_______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org