Sample 53: Using Failover Endpoints to Handle Peak Loads

Introduction

This sample demonstrates how you can handle peak load scenarios using failover endpoints. Here three failover endpoints are used in order to handle the requests that are coming in.

Prerequisites

For a list of prerequisites, see Prerequisites to Start the ESB Samples.

Building the sample

The XML configuration for this sample is as follows:

<definitions xmlns="http://ws.apache.org/ns/synapse">
    <sequence name="main" onError="errorHandler">
        <in>
            <send>
                <endpoint>
                    <failover>
                        <endpoint>
                            <address uri="http://localhost:9001/services/LBService1">
                                <enableAddressing/>
                                <suspendDurationOnFailure>60</suspendDurationOnFailure>
                            </address>
                        </endpoint>
                        <endpoint>
                            <address uri="http://localhost:9002/services/LBService1">
                                <enableAddressing/>
                                <suspendDurationOnFailure>60</suspendDurationOnFailure>
                            </address>
                        </endpoint>
                        <endpoint>
                            <address uri="http://localhost:9003/services/LBService1">
                                <enableAddressing/>
                                <suspendDurationOnFailure>60</suspendDurationOnFailure>
                            </address>
                        </endpoint>
                    </failover>
                </endpoint>
            </send><drop/>
        </in>
        <out>
            <!-- Send the messages where they have been sent (i.e. implicit To EPR) -->
            <send/>
        </out>
    </sequence>
    <sequence name="errorHandler">
        <makefault>
            <code value="tns:Receiver" xmlns:tns="http://www.w3.org/2003/05/soap-envelope"/>
            <reason value="COULDN'T SEND THE MESSAGE TO THE SERVER."/>
        </makefault>

        <header name="To" action="remove"/>
        <property name="RESPONSE" value="true"/>
        <send/>
    </sequence>
</definitions>

This configuration file synapse_sample_53.xml is available in the <ESB_HOME>/repository/samples directory.

To build the sample

Start the ESB with the sample 53 configuration. For instructions on starting a sample ESB configuration, see Starting the ESB with a sample configuration.

The operation log keeps running until the server starts, which usually takes several seconds. Wait until the server has fully booted up and displays a message similar to "WSO2 Carbon started in n seconds."
Start three instances of the sample Axis2 server on HTTP ports 9001, 9002 and 9003 respectively and give unique names to each server. For instructions on starting the Axis2 server, see Starting the Axis2 server.
Deploy the back-end service LoadbalanceFailoverService. For instructions on deploying sample back-end services, see Deploying sample back-end services.

Executing the sample

The sample client used here is the Load Balance and Failover Client.

To execute the sample client

Run the following command from the <ESB_HOME>/samples/axis2Client directory, to send infinite requests.
```
ant loadbalancefailover
```
While the client is running, stop the server named MyServer1.
Stop the server named MyServer2.
Stop the server named MyServer3.

Analyzing the output

According to the configuration file for this sample, messages are sent with the failover behavior. Initially the server at port 9001 is treated as the primary server and the other two are treated as back up servers. Messages will always be directed only to the primary server. If the primary server fails, the next listed server is selected as the primary server. Therefore, messages are sent successfully as long as there is at least one active server. To test this, run the loadbalancefailover client to send infinite requests as follows:

ant loadbalancefailover

When you run the client, infinite requests will be sent and you will see that all requests are processed by MyServer1. This is because the requests are always directed only to the primary server.

Here, the server at port 9001 is treated as the primary server and the other two are treated as back up servers. Therefore, all requests are processed by the server at port 9001 which is named as MyServer1.

Once you stop MyServer1 and analyze the log output on the client console, you will see that all subsequent requests are processed by MyServer2.

If MyServer1 is stopped after the request 127, the log output will be as follows:

...
[java] Request: 125 ==> Response from server: MyServer1
[java] Request: 126 ==> Response from server: MyServer1
[java] Request: 127 ==> Response from server: MyServer1
[java] Request: 128 ==> Response from server: MyServer2
[java] Request: 129 ==> Response from server: MyServer2
[java] Request: 130 ==> Response from server: MyServer2
...

When all servers are stopped, the error sequence will be activated and you will see the following fault message on the client console.

[java] COULDN'T SEND THE MESSAGE TO THE SERVER.

When a server failure is detected, the failed server will be added once again to the active servers list after 60 seconds. This is because <suspendDurationOnFailure> is set to 60 in the configuration file. Therefore, if you have restarted any of the stopped servers and have stopped all other servers, messages will be directed to the server that is restarted.