This section explains how the members of the cache cluster can be defined. In many cases, the default multicast values in the provided engine property files work out of the box, with no configuration. Two methods are available: multicast, and well-known-addresses.
With multicast cache cluster configuration, the cluster membership is established using the multicast IP address and port. When a BusinessEvents node subscribes to this multicast IP address it broadcasts information about its presence to the address.
Multicast discovery is used by default. The default values provided mean you may not have to configure any discovery-related properties. However, if you deploy multiple BusinessEvents projects in your environment, you must specify different multicast address and port settings for each project.
You can use multicast when instances of an application are deployed to hosts in the same subnet, or across subnets when broadcast is enabled between the subnets.
The object management layer uses multicast to discover new nodes and add them to the cache cluster. Similarly when nodes are removed or moved to a different server, the multicast protocol ensures that members are kept current without any additional configuration.
For the above reason, multicast discovery requires less maintenance than the well-known-address method, which requires configuration updates for all such changes.
Cluster heartbeat The most senior member in the cluster issues a periodic heartbeat using multicast. The rate is configurable and defaults to one per second.
Message delivery Messages intended for multiple cluster members are often sent using multicast, instead of unicasting the message one time to each member.
For peer-to-peer communications and data transfer, the object management layer then uses unicast as needed. Peer-to-peer connections are automatically established with other servers listening on the multicast address.
Well-known-address configuration uses direct member-to-member (point-to-point) communication, including messages, asynchronous acknowledgements (ACKs), asynchronous negative acknowledgements (NACKs) and peer-to-peer heartbeats. The addresses are "well known" to the extent that they are known to each server in the cluster.
Use well-known-addresses instead of multicast to define the cluster participants when multicast is undesirable or unavailable, for example, if nodes are deployed to different subnets and broadcast between the subnets is not enabled.
You must ensure that the well known address information is updated on all machines to account for system changes, such as adding, removing, and moving nodes to different machines.