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-hopsset to 1.
NoteIn 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.
220.127.116.11. Configuring Cluster Connections
Cluster connections are configured in server configuration files (
domain.xml) in the element
cluster-connection. There can be zero or more cluster connections defined per HornetQ server.
<cluster-connections> <cluster-connection name="my-cluster"> <address>jms</address> <connector-ref>netty-connector</connector-ref> <check-period>1000</check-period> <connection-ttl>5000</connection-ttl> <min-large-message-size>50000</min-large-message-size> <call-timeout>5000</call-timeout> <retry-interval>500</retry-interval> <retry-interval-multiplier>1.0</retry-interval-multiplier> <max-retry-interval>5000</max-retry-interval> <reconnect-attempts>-1</reconnect-attempts> <use-duplicate-detection>true</use-duplicate-detection> <forward-when-no-consumers>false</forward-when-no-consumers> <max-hops>1</max-hops> <confirmation-window-size>32000</confirmation-window-size> <call-failover-timeout>30000</call-failover-timeout> <notification-interval>1000</notification-interval> <notification-attempts>2</notification-attempts> <discovery-group-ref discovery-group-name="my-discovery-group"/> </cluster-connection> </cluster-connections>The following table defines the configurable attributes:
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 (
Table 20.13. Cluster Connections Configurable Attributes
| ||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.|
| ||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|
| ||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|
| ||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|
| ||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|
| ||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|
| || 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 ||500 milliseconds|
| || This is used to increment the ||1|
| ||This refers to the maximum delay (in milliseconds) for retries||2000 milliseconds|
| ||This defines the number of times the system will try to connect a node on the cluster||-1 (infinite retries)|
| ||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|
| ||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|
| ||This determines how messages are load balanced to other HornetQ serves which are connected to this server||-1|
| ||The size (in bytes) of the window used for sending confirmations from the server connected to||1048576|
| ||This is used when a call is made during a failover attempt||-1 (no timeout)|
| ||This determines how often (in milliseconds) the cluster connection must broadcast itself when attaching to the cluster||1000 milliseconds|
| ||This defines as to how many times the cluster connection must broadcast itself when connecting to the cluster||2|
| ||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|
<cluster-user>HORNETQ.CLUSTER.ADMIN.USER</cluster-user> <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.