Hi Isuru, We need to make sure that cluster notifications are synced across the cluster as soon as possible. Also, it is not guaranteed that another notifcation will be generated given that one occurs. Therefore, it could be a problem if we wait for a batch. But one thing we can do is, having a scheduled task to insert the notifications periodically (where the intervel will be less than 1 second). But we need to evaluate if this is necessary since there might probably not be many cluster notifications at a particular time and this will increase the time taken for events to be synced. I think we'll need to test both ways to see the impact. Thanks a lot for the suggestion.
Thank you, Sasikala On Fri, Aug 12, 2016 at 5:54 PM, Isuru Haththotuwa <[email protected]> wrote: > Hi Sasikala, > > On Wed, Aug 10, 2016 at 4:19 PM, Sasikala Kottegoda <[email protected]> > wrote: > >> Hi all, >> >> Currnetly in MB, we have used Hazelcast to handle all cluster operations >> such as coordinator election, cluster notification synchronization, etc. >> When the network partitions, the cluster ends up in a messy situation where >> following issues are prominent. >> >> - multiple coordinators are elected >> - cluster-wide notifications are not sent >> >> In order to resolve the issue of multiple coordinators being elected, we >> have implemented an RDBMS based coordinator election mechanism and a >> discussion on that can be found in the mail thread with the subject [1] >> >> In order to resolve the issue of cluster-wide notification >> synchronization, we are planning to implement a method based on RDBMS and >> the details are as follows: >> >> *Cluster notification types that are being sent:* >> >> - Queue changes (Add, Delete, Purge) >> - Binding changes(Add, Delete) >> - Exchange changes (Add, Delete) >> - Subscription changes (Add, Delete, Disconnect) >> >> *Existing method of cluster communication using Hazelcast:* >> We have used Hazelcast Reliable topics for all of the above notification >> types and have added each node in the cluster as a subscriber to these >> topics. >> >> *Proposed implementation using RDBMS:* >> The node that generates a cluster notification will duplicate it >> according to the number of nodes in the cluster and store it in a table. >> Each node will periodically check for the existence of a notification in >> the table destined to it and process accordingly. >> > IMO If we update the DB for each and every type of changes that are > mentioned above, this could be a bottleneck wrt DB access. Would it be > viable functionality-wise to write to the DB in a batch, rather than for > each change? > >> >> Thoughts? >> >> [1] "[Architecture] RDBMS based coordinator election algorithm for MB" >> >> -- >> Sasikala Kottegoda >> *Software Engineer* >> WSO2 Inc., http://wso2.com/ >> lean. enterprise. middleware >> Mobile: +94 774835928 >> >> [image: https://wso2.com/signature] <https://wso2.com/signature> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks and Regards, > > Isuru H. > +94 716 358 048* <http://wso2.com/>* > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sasikala Kottegoda *Software Engineer* WSO2 Inc., http://wso2.com/ lean. enterprise. middleware Mobile: +94 774835928 [image: https://wso2.com/signature] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
