Reference: Configure Cluster Connections
This topic has not yet been written. The content below is from the topic description.
In the above cluster connection all parameters have been explicitly specified. In practice you might use the defaults for some. address. Each cluster connection only applies to messages sent to an address that starts with this value. In this case, this cluster connection will load balance messages sent to address that start with jms. This cluster connection, will, in effect apply to all JMS queue and topic subscriptions since they map to core queues that start with the substring "jms". The address can be any value and you can have many cluster connections with different values of address, simultaneously balancing messages for those addresses, potentially to different clusters of servers. By having multiple cluster connections on different addresses a single HornetQ Server can effectively take part in multiple clusters simultaneously. Be careful not to have multiple cluster connections with overlapping values of address, e.g. "europe" and "europe.news" since this could result in the same messages being distributed between more than one cluster connection, possibly resulting in duplicate deliveries. This parameter is mandatory. retry-interval. We mentioned before that, internally, cluster connections cause bridges to be created between the nodes of the cluster. If the cluster connection is created and the target node has not been started, or say, is being rebooted, then the cluster connections from other nodes will retry connecting to the target until it comes back up, in the same way as a bridge does. This parameter determines the interval in milliseconds between retry attempts. It has the same meaning as the retry-interval on a bridge (as described in Chapter 36, Core Bridges). This parameter is optional and its default value is 500 milliseconds. use-duplicate-detection. Internally cluster connections use bridges to link the nodes, and bridges can be configured to add a duplicate id property in each message that is forwarded. If the target node of the bridge crashes and then recovers, messages might be resent from the source node. By enabling duplicate detection any duplicate messages will be filtered out and ignored on receipt at the target node. This parameter has the same meaning as use-duplicate-detection on a bridge. For more information on duplicate detection, please see Chapter 37, Duplicate Message Detection. This parameter is optional and has a default value of true. forward-when-no-consumers. This parameter determines whether messages will be distributed round robin between other nodes of the cluster irrespective of whether there are matching or indeed any consumers on other nodes. If this is set to true then each incoming message will be round robin'd even though the same queues on the other nodes of the cluster may have no consumers at all, or they may have consumers that have non matching message filters (selectors). Note that HornetQ will not forward messages to other nodes if there are no queues of the same name on the other nodes, even if this parameter is set to true. If this is set to false then HornetQ will only forward messages to other nodes of the cluster if the address to which they are being forwarded has queues which have consumers, and if those consumers have message filters (selectors) at least one of those selectors must match the message. This parameter is optional, the default value is false. max-hops. When a cluster connection decides the set of nodes to which it might load balance a message, those nodes do not have to be directly connected to it via a cluster connection. HornetQ can be configured to also load balance messages to nodes which might be connected to it only indirectly with other HornetQ servers as intermediates in a chain. This allows HornetQ to be configured in more complex topologies and still provide message load balancing. We'll discuss this more later in this chapter. The default value for this parameter is 1, which means messages are only load balanced to other HornetQ serves which are directly connected to this server. This parameter is optional. discovery-group-ref. This parameter determines which discovery group is used to obtain the list of other servers in the cluster that this cluster connection will make connections to.