## Configuring a Simple Broker Cluster

### Simple cluster architecture

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.

Figure 6.1. Simple Cluster Architecture

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.

### Failover protocols

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:

- Failover Protocol .

- Dynamic Discovery Protocol .

- Discovery Agents .

### Limitations of simple broker clusters

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.

### Steps to create multiple broker instance

Perform the following steps to create multiple message broker instances:

1. Create a directory for the new broker configuration .

2. Copy configuration files .

3. Customize port numbers .

4. Customize the broker name .

5. (Optionally) Disable network connectors .

6. Create a script to run the broker

7. Repeat as necessary .

### Create a directory for the new broker configuration

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

### Copy configuration files

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.

### Customize port numbers

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`.

### Customize the broker name

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
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.

### (Optionally) Disable network connectors

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
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.

### Create a script to run the broker

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 as necessary

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

### Example broker cluster

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).