Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

For 1.1 onwards we're implementing a range of Group Organisation protocols to help arrange nodes into groups. To get an idea of the progress we're making, check out the javadocs.


The basic idea is we want to arrange nodes into logical groups. Each group acts as a single logical entity.

For example to implement the master/slave type High Availability (HA) model, we may wish to have just 1 single group with a master node and a collection of one or more slave nodes. If the master goes down or becomes unavailable or overworked; we can failover to a slave.

The default GroupModel supports this behaviour and can handle one or more groups. So there could be several groups (with a single master and multiple slaves) for different instances of a service. You can configure the GroupModel with a maximum number of groups - so if you wish you can restrict the number of groups.

Buddy Groups

The organisation policy for buddy groups is often a little different. Generally we want each node in a cluster to be a master node, in its own group - but for other nodes in the cluster to be buddies to act as backups.

(We may wish to restrict some nodes from being master nodes, so there is an optional masterNodeFilter we can use to restrict those nodes on the BuddyGroupModel being master nodes).

So the BuddyGroupModel will create a group for every possble node joining and then assign buddy groups from other members in the cluster.

  • No labels