WildFly HornetQ Cluster Connection Configuration

Internal

• WildFly HornetQ-Based Messaging Subsystem Configuration

Overview

A cluster connections represents an unidirectional communication channel between nodes. More details about the cluster connection concepts are available here: Cluster Connection Concepts. 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>

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.

min-large-message-size, call-timeout, retry-interval, retry-interval-multiplier, max-retry-interval, reconnect-attempts, confirmation-window-size, call-failover-timeout, notification-interval, notification-attempts, discovery-group-ref

• Cluster Connections Configurable Attributes