20.13.4. Server Side Load Balancing

There is one important cluster topology:
  • Symmetric Cluster: In a symmetric cluster every cluster node is connected directly to every other node in the cluster. To create a symmetric cluster every node in the cluster defines a cluster connection with the attribute max-hops set to 1.


    In a symmetric cluster each node knows about all the queues that exist on all the other nodes and what consumers they have. With this knowledge it can determine how to load balance and redistribute messages around the nodes. Configuring Cluster Connections

Cluster connections are configured in server configuration files (standalone.xml and domain.xml) in the element cluster-connection. There can be zero or more cluster connections defined per HornetQ server.
  <cluster-connection name="my-cluster">
     <discovery-group-ref discovery-group-name="my-discovery-group"/>
The following table defines the configurable attributes:

Table 20.13. Cluster Connections Configurable Attributes

Attribute Description Default
address Each cluster connection only applies to messages sent to an address that starts with this value. The address can be any value and you can have many cluster connections with different values of addresses, simultaneously balancing messages for those addresses, potentially to different clusters of servers. This does not use wild card matching.
connector-ref This is a compulsory attribute which refers to the connector sent to other nodes in the cluster so that they have the correct cluster topology
check-period This refers to the time period (in milliseconds) which is used to verify if a cluster connection has failed to receive pings from another server 30,000 milliseconds
connection-ttl This specifies how long a cluster connection must stay alive if it stops receiving messages from a specific node in the cluster 60,000 milliseconds
min-large-message-size If the message size (in bytes) is larger than this value then it will be split into multiple segments when sent over the network to other cluster members 102400 milliseconds
call-timeout This specifies the time period (milliseconds) for which a packet sent over a cluster connection waits (for a reply) before throwing an exception 30,000 milliseconds
retry-interval If the cluster connection is created between nodes of a cluster and the target node has not been started, or is being rebooted, then the cluster connections from other nodes will retry connecting to the target until it comes back up. The parameter retry-interval defines the interval (milliseconds) between retry attempts 500 milliseconds
retry-interval-multiplier This is used to increment the retry-interval after each retry attempt 1
max-retry-interval This refers to the maximum delay (in milliseconds) for retries 2000 milliseconds
reconnect-attempts This defines the number of times the system will try to connect a node on the cluster -1 (infinite retries)
use-duplicate-detection 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. True
forward-when-no-consumers This parameter determines whether or not messages will be distributed in a round robin fashion between other nodes of the cluster regardless of whether there are matching or indeed any consumers on other nodes False
max-hops This determines how messages are load balanced to other HornetQ serves which are connected to this server -1
confirmation-window-size The size (in bytes) of the window used for sending confirmations from the server connected to 1048576
call-failover-timeout This is used when a call is made during a failover attempt -1 (no timeout)
notification-interval This determines how often (in milliseconds) the cluster connection must broadcast itself when attaching to the cluster 1000 milliseconds
notification-attempts This defines as to how many times the cluster connection must broadcast itself when connecting to the cluster 2
discovery-group-ref This parameter determines which discovery group is used to obtain the list of other servers in the cluster which the current cluster connection will make connections to
When creating connections between nodes of a cluster to form a cluster connection, HornetQ uses a cluster user and cluster password which is defined in server configuration files (standalone.xml and domain.xml):
<cluster-password>NEW USER</cluster-password>


It is important to change the default values of these credentials to prevent remote clients from making connections to the server using the default values.