WildFly HornetQ Cluster Connection Configuration: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(12 intermediate revisions by the same user not shown)
Line 5: Line 5:
=Overview=
=Overview=


A cluster connections represents an ''unidirectional'' communication channel between nodes. More details about the cluster connection concepts are available here: [[WildFly_HornetQ-Based_Messaging_Subsystem_Concepts#Cluster_Connection|Cluster Connection Concepts]]. It is configured as follows:
A cluster connections represents an ''unidirectional'' communication channel between nodes. More details about the cluster connection concepts are available here: [[WildFly_HornetQ-Based_Messaging_Subsystem_Concepts#Cluster_Connection|Cluster Connection Concepts]].  
 
A cluster connection that uses static connections - explicitly defined topology - It is configured as follows:


<pre>
<pre>
Line 27: Line 29:
   ...
   ...
   </hornetq-server>
   </hornetq-server>
</subsystem>
</pre>
A cluster connection that uses dynamic discovery is configured as follows:
<pre>
<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>
</subsystem>
</pre>
</pre>
Line 45: Line 72:


==<tt>connection-ttl</tt>==
==<tt>connection-ttl</tt>==
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.
==<tt>use-duplicate-detection</tt>==
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 <tt>true</tt>.
==<tt>forward-when-no-consumers</tt>==
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 <tt>false</tt>.


==<tt>max-hops</tt>==
==<tt>max-hops</tt>==


In [[WildFly_HornetQ-Based_Messaging_Subsystem_Concepts#Symmetric_Cluster|symmetric clusters]], <tt>max-hops</tt> must be set to 1.
This determines how messages are load balanced to other HornetQ nodes which are connected to this node In [[WildFly_HornetQ-Based_Messaging_Subsystem_Concepts#Symmetric_Cluster|symmetric clusters]], <tt>max-hops</tt> must be set to 1.


==<tt>static-connectors</tt>==
==<tt>static-connectors</tt>==
Line 55: Line 96:


<blockquote style="background-color: Gold; border: solid thin Goldenrod;">
<blockquote style="background-color: Gold; border: solid thin Goldenrod;">
:<br>It has been determined experimentally that only the first connector listed under <tt><static-connectors></tt> is used, the others are ignored, so it seems that a cluster connection is a point-to-point affair.<br><br>
:<br>It has been determined experimentally that only the first connector listed under <tt><static-connectors></tt> is used, the others are ignored, so it seems that a cluster connection is a point-to-point affair. See more [[WildFly_HornetQ-Based_Messaging_Subsystem_Concepts#Cluster_Connection|Cluster Connection Concepts]].<br><br>
</blockquote>
</blockquote>
==<tt>min-large-message-size</tt>==
==<tt>call-timeout</tt>==
{{External|https://access.redhat.com/solutions/318693}}
==<tt>retry-interval</tt>==
==<tt>retry-interval-multiplier</tt>==
==<tt>max-retry-interval</tt>==
==<tt>reconnect-attempts</tt>==
==<tt>confirmation-window-size</tt>==
==<tt>call-failover-timeout</tt>==
==<tt>notification-interval</tt>==
==<tt>notification-attempts</tt>==
==<tt>discovery-group-ref</tt>==
* [https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.4/html/Administration_and_Configuration_Guide/sect-HornetQ_Clustering.html#sect-Server_Side_Load_Balancing Cluster Connections Configurable Attributes]

Latest revision as of 19:08, 26 June 2017

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.

min-large-message-size

call-timeout

https://access.redhat.com/solutions/318693

retry-interval

retry-interval-multiplier

max-retry-interval

reconnect-attempts

confirmation-window-size

call-failover-timeout

notification-interval

notification-attempts

discovery-group-ref