WildFly HornetQ Cluster Connection Configuration
Internal
Overview
A cluster connections represents an unidirectional communication channel between nodes. More details about the cluster connection concepts are available here: Cluster Connection Concepts.
A cluster connection that uses static connections - explicitly defined topology - It is configured as follows:
<subsystem xmlns="urn:jboss:domain:messaging:1.4">
<hornetq-server name="active-hq-node">
...
<cluster-connections>
<cluster-connection name="load-balancing-to-lb2-and-lb3">
<address>jms</address>
<connector-ref>netty-inbound</connector-ref>
<retry-interval>500</retry-interval>
<use-duplicate-detection>true</use-duplicate-detection>
<forward-when-no-consumers>true</forward-when-no-consumers>
<max-hops>1</max-hops>
<static-connectors>
<connector-ref>lb2</connector-ref>
<connector-ref>lb3</connector-ref>
</static-connectors>
</cluster-connection>
</cluster-connections>
...
</hornetq-server>
</subsystem>
A cluster connection that uses dynamic discovery is configured as follows:
<subsystem xmlns="urn:jboss:domain:messaging:1.4">
<hornetq-server>
[...]
<discovery-groups>
<discovery-group name="dg-group1">
<socket-binding>messaging-group</socket-binding>
<refresh-timeout>10000</refresh-timeout>
</discovery-group>
</discovery-groups>
[...]
<cluster-connections>
<cluster-connection name="my-cluster">
<address>jms</address>
<connector-ref>netty</connector-ref>
<discovery-group-ref discovery-group-name="dg-group1"/>
</cluster-connection>
</cluster-connections>
[...]
</hornetq-server>
</subsystem>
Configuration Elements
address
Each cluster connection only applies to messages sent to an address that starts with this value. The address can be any value and there can be many cluster connections with different address values, balancing messages for those addresses, potentially to different clusters of servers. This does not use wild card matching
connector-ref
The connector-ref is a required attribute that contains the connector value to be sent to the target of this cluster connection. This insures that the target node knows the connector information of the initiator node. It must be the name of a connector declared in the <connectors> configuration element of the initiator (this) HornetQ node.
check-period
The time period in milliseconds which is used to verify if a cluster connection has failed to receive pings from the target. The default value is 30,000 milliseconds.
connection-ttl
How long a cluster connection must stay alive (in milliseconds) if it stops receiving messages from a specific node in the cluster. The default value is 60,000 milliseconds.
use-duplicate-detection
Configures the underlying core bridge 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 origin node. By enabling duplicate detection any duplicate messages will be filtered out and ignored on receipt at the target node.
Default is 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.
Default is false.
max-hops
This determines how messages are load balanced to other HornetQ nodes which are connected to this node In symmetric clusters, max-hops must be set to 1.
static-connectors
One Target Connector Only
It has been determined experimentally that only the first connector listed under <static-connectors> is used, the others are ignored, so it seems that a cluster connection is a point-to-point affair. See more Cluster Connection Concepts.