HornetQ Deploying a Distributed Topic

Internal

• WildFly Messaging Subsystem Configuration

Overview

This article explains how to deploy a distributed topic - meaning that messages are internally distributed amongst the HornetQ nodes that have the topic deployed on them. The underlying cluster connection that does the internal message distribution is configured to only handle messages destined to the specific topic we're distributing, maintaining all other destinations isolated.

The example assumes three nodes (n1, n2 and n3).

Deploy the Topic on All Nodes

Deploy the topic on all nodes. Use the usual declaration:

<jms-destinations>
  ...
  <jms-topic name="novaordis">
    <entry name="topic/novaordis"/>
    <entry name="java:jboss/exported/topic/novaordis"/>
  </jms-topic>
</jms-destinations>

At this point, the topic is deployed locally on all three nodes. Topic subscriptions will only receive messages sent to the topic on the node the subscription was established on.

The name of the topic is important, as we will configure cluster connections to only handle messages sent to the HornetQ core address associated with the topic ("jms.topic.novaordis"). For more details on the relationship between HornetQ core queues, addresses and JMS topics, see HornetQ Address.

Configure the Cluster Connection on All Nodes

Cluster connections are unidirectional. For bi-directional propagation of messages between two nodes, two different cluster connections, each connection in an opposite direction, must be established between those two nodes.

Note the cluster connection address value, it limits the messages handled by the cluster connection only to those sent to the topic.

Deploy the cluster connection that will distribute topic messages among nodes.

For the node "n1", the configuration is similar to the following example. For n2 and n2, similar configurations should be applied:

<server>
  ...

  <subsystem xmlns="urn:jboss:domain:messaging:1.4">
    <hornetq-server>
      ...
      <connectors>
        ...
        <netty-connector name="n2" socket-binding="n2-binding"/>
        <netty-connector name="n3" socket-binding="n3-binding"/>
      </connectors>

      ...

      <cluster-connections>

        <cluster-connection name="n1-to-n2">
          <address>jms.topic.novaordis</address>
          <connector-ref>netty</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>n2</connector-ref>
           </static-connectors>
         </cluster-connection>

         <cluster-connection name="n1-to-n3">
          <address>jms.topic.novaordis</address>
          <connector-ref>netty</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>n3</connector-ref>
           </static-connectors>
         </cluster-connection>

       </cluster-connections>

    </hornetq-server>
  </subsystem>

  ...

  <socket-binding-group ...>
    ...
    <outbound-socket-binding name="n2-binding">
      <remote-destination host="n2-host" port="5445"/>
    </outbound-socket-binding>
    <outbound-socket-binding name="n3-binding">
      <remote-destination host="n3-host" port="5445"/>
    </outbound-socket-binding>
  </socket-binding-group>

</server>