Note that WSO2 EI is shipped with the following changes to what is mentioned in this documentation:
repository/samples/directory that includes all Integration profile samples is changed to
repository/samples/resources/directory that includes all artifacts related to the Integration profile samples is changed to
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.
For a list of prerequisites, see Prerequisites to Start the ESB Samples.
Building the sample
The XML configuration for this sample is as follows:
This configuration file
synapse_sample_53.xml is available in the
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/axis2Clientdirectory, to send infinite requests.
- 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:
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:
When all servers are stopped, the error sequence will be activated and you will see the following fault message on the client console.
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.