Configuring TIBCO EMS: Fault-Tolerance

We will configure TIBCO Enterprise Message Service from building a set of fault-tolerant pairs to putting those pairs into a load-balanced environment. The solution can be built on a single machine and tested, as shown below. In a real deployment scenario, you would want to have each machine be distinct.

In the diagram above, you see four EMS Server instances with each Fault-Tolerant (FT) pair sharing the same EMS “Server Name”, and you see the client with a complex URL that is constructed such that you have FT pairs separated by a comma and those pairs in a Load-Balanced (LB) arrangement separated by a vertical bar (or pipe symbol).

To make this arrangement work on a single machine, the individual services are on distinct ports. The first FT pair has an active server on port 7222 with a backup server listening on port 7224, for example. The primary is the one that starts first.

Fault Tolerant Configuration
Configure the Daemon
To configure Fault-Tolerance, we will need to configure only two types of files:
tibemsd.conf – configure the daemon process
factories.conf - build FT factories as needed

Since we have a FT pair, we will create two files for the daemon processes so that we can start them with different configurations on the same machine. Given different machines, each machine will only need one of each of the types of files, but for our example, some types of files are shared while others need to be replicated to provide unique features.

Below, you will see the first tibemsd.conf file, renamed tibemsd1.conf to provide a unique identity. Note the bold items for server, store, listen, and ft_active – these are the required entries for FT configuration; the addition of the routing item is included at this time since we will be using this FT pair in an LB environment.

The second configuration will be accomplished by making a copy of the first and renaming it, prior to making some minor modifications. In the example below, we have named the file tibemsd2.conf

Note how the ft_active port is the same as the listen port of the other configuration, and vice versa! This is the only change necessary. This is akin to a “roll-over” cable and permits each server to receive heartbeats from the other. The active server has an exclusive lock on the storage.

Configure a Fault-Tolerant Factory

Edit factories.conf and create two factories, one for queues and one for topics. The standard factories.conf come with these preconfigured as FTTopicConnectionFactory and FTQueueConnectionFactory. The syntax in the file looks like this:

[FTTopicConnectionFactory]

type = topic

url = tcp://localhost:7222,tcp://localhost:7224

[FTQueueConnectionFactory]

type = queue

url = tcp://localhost:7222,tcp://localhost:7224

An alternate method to editing this file is to start up one of these daemons and to access the EMS Administration Tool and enter the command:

create factory FTQ queue url=tcp://localhost:7222,tcp://localhost:7224

This will create a ConnectionFactory for queues that exposes a Fault-Tolerant URL, as shown by the two comma-separated host specific URLs. When a Client requests the FTQ factory object through JNDI, it will have this complex URL associated with these two servers.

Set track_message_ids Parameter
There will be Fault-Tolerant cases where a failure occurs before the Provider can acknowledge the receipt of the message, so to prevent duplicate messages, you set the track_message_ids parameter in the tibemsd.conf file:
track_message_ids = enabled

Starting a Fault-Tolerant Pair

Simply start two instances of the EMS daemon where each instance points to a specific configuration file (shown is from a Windows Batch file):
start tibemsd -config tibemsd1.conf

start tibemsd –config tibemsd2.conf

Monitoring a Fault-Tolerant Pair

The EMS Administration Tool needs to connect to a particular instance, so start the Tool and for the connect string enter:

connect tcp://localhost:7222

Start up another instance, and change the connect string to:
connect tcp://localhost:7224

In this manner you will be able to see a client fail-over by issuing the “show connections” command.