LibraryLink ToToggle FramesPrintFeedback

Configuring a Simple Broker Cluster

Figure 6.1 shows an example of the kind of simple broker cluster that is the subject of discussion in this chapter, where the cluster shown in Figure 6.1 consists of just two brokers: broker A and broker B.


The preceding figure illustrates the simplest type of cluster, where no network connectors are enabled on the brokers and the brokers remain unaware of each other (isolated brokers). Assuming that the producers do not care which consumer processes the messages, this cluster architecture can be useful for balancing load across multiple hosts. There are, however, some serious limitations with this type of cluster.

The cluster architecture shown in Figure 6.1 can support some simple modes of failover protection. In particular, if a producer or consumer loses its connection to a broker, it can use one of the failover URIs to manage reconnection to an alternative broker in the cluster. Currently, the following failover protocols support reconnection logic:

The cluster architecture shown in Figure 6.1 suffers from the following limitations:

  • Each broker must have a consumer for each type of queue.

  • If a consumer for a particular queue on a particular broker becomes unavailable, messages on that queue will accumulate in the broker without being processed.

  • Producers have no way of finding out whether a particular queue instance has an associated consumer.

In principle, these limitations can be overcome by linking brokers together using network connectors.

Perform the following steps to create multiple message broker instances:

Create a new directory to hold the configuration files for a new broker instance. For example, in your working directory, FuseWorking, create a directory, broker_a, for broker A by entering the following command:

mkdir FuseWorking/broker_a

From the FUSE Message Broker install directory, InstallDir, copy the conf and webapps directories into the broker_a directory. For example:

Windows

mkdir FuseWorking\broker_a\conf
copy InstallDir\conf FuseWorking\broker_a\conf
mkdir FuseWorking\broker_a\webapps
copy InstallDir\webapps FuseWorking\broker_a\webapps

UNIX

cp InstallDir/conf FuseWorking/broker_a/conf
cp InstallDir/webapps FuseWorking/broker_a/webapps

Where the conf directory contains the basic configuration files for the broker and the webapps directory contains the files required to run the Web console management tool.

You must customize the port numbers used by broker A, in order to avoid clashes with other brokers. To customize the port numbers, edit the broker_a/conf/activemq.xml configuration file. For example, you might customize the transport connector ports as follows:

    <transportConnectors>
        <transportConnector name="openwire"
                            uri="tcp://localhost:61716"
                           discoveryUri="multicast://default"/>
        ...
    </transportConnectors>

Where the TCP connector port has been changed from 61616 to 61716. You also need to customize the port for the servlet engine (which hosts the Web console application), as follows:

    <jetty xmlns="http://mortbay.com/schemas/jetty/1.0">
        <connectors>
            <nioConnector port="8171" />
        </connectors>
        ...
    </jetty>

Where the servlet engine port has been changed from 8161 to 8171.

You must also customize the broker name, by setting the brokerName attribute of the broker element. For example, to set the broker name for broker A, edit the broker_a/conf/activemq.xml configuration file as follows:

<broker xmlns="http://activemq.org/config/1.0"
    brokerName="brokera"
    dataDirectory="${activemq.base}/data">
    ...
</broker>

Where the broker name is set to broker_a.

[Note]Note

It is important for each broker in a cluster to have a distinct name. For example, discovery agents and network connectors require that each broker in the cluster has a distinct name.

By default, the standard broker configuration comes with a network connector enabled. For the basic cluster discussed in this chapter, however, each broker is isolated and unaware of its peers. To configure this type of cluster, you must edit the broker_a/conf/activemq.xml configuration file, commenting out any network connector elements, networkConnector, as shown in the following example:

    <networkConnectors>
      <!-- Comment out the network connectors ... -->
      <!--
      <networkConnector name="default-nc"
                       uri="multicast://default"/>
      -->
    </networkConnectors>
[Note]Note

Of course, network connectors are useful and a network of brokers is much more responsive and flexible than a simple collection of isolated broker instances. If you prefer, you can leave the network connectors enabled, but you should be aware that the examples will behave somewhat differently from the descriptions given in the text.

The standalone message broker, activemq, reads the environment variable, ACTIVEMQ_BASE, to determine the location of its configuration directory. Hence, in order to run a standalone broker using the broker A configuration, you must set ACTIVEMQ_BASE to the directory, FuseWorking/broker_a before running activemq.

The easiest approach to take is to create a dedicated script to run broker A. For example, you might create a script similar to the following:

Windows

Create a Windows .bat file, broker_a.bat, according to the following outline:

@echo off
REM Set generic FUSE Message Broker environment
REM ... (Not shown - for details, see install guide)
set ACTIVEMQ_BASE=FuseWorking\broker_a
echo Running Broker A...
activemq

UNIX

Assuming you are using a Bourne shell, create a shell script, broker_a, according to the following outline:

#! /bin/sh
# Set generic FUSE Message Broker environment
# ... (Not shown - for details, see install guide)
ACTIVEMQ_BASE=FuseWorking/broker_a; export ACTIVEMQ_BASE
echo Running Broker A...
activemq

Repeat the preceding steps to create as many broker instances as required—for example, broker B, C, D, and so on.

To run the examples described in this chapter, two brokers are required: broker A and broker B. Broker A is configured with the following transport connectors:

    <transportConnectors>
        <transportConnector
            name="openwire" uri="tcp://localhost:61716" discoveryUri="multicast://default"/>
    </transportConnectors>

And broker B is configured with the following transport connectors:

    <transportConnectors>
        <transportConnector
            name="openwire" uri="tcp://localhost:61816" discoveryUri="multicast://default"/>
    </transportConnectors>

Where the TCP ports are configured to have distinct values (61716 and 61816, respectively). You must also ensure that any other port numbers are configured to be distinct (for example, the servlet engine port inside the <jetty> tag).