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. 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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
