Setting up IEP SE in a High-Availability and Failover Mode
IEP SE can be installed on multiple standalone GlassFish instances and configured to provide high availability in case of failure of one of the instances. This is very similar to running IEP SE in GlassFish cluster. However, components (e.g. IEP SE and BPEL SE), have not been extensively tested to work in GlassFish cluster. Therefore, it is recommended to use the feature mentioned here to achieve high availability and failover when using IEP SE.This page explains how to set up your environment, and also explains how to use a sample application to test your environemnt.
You will need to follow these steps to get your environment running
- Install a database server
- Install and configure two or more GlassFish instances
- Deploy sample application and test
Install a Database Server
IEP SE depends on the database server to provide its High-Availablity and Failover feature. Therefore, the database itself needs to be set up in high availability mode. Enterprise databases like Oracle have their own mechanism to provide high availability. Please refer to the database vendor's documentation to set up the database in high availabilty mode.For this exercise, we can use Derby and assume that it is highly available. Specifically is, we will use Derby that comes bundled with GlassFish. We need to start the database server on only one of the GlassFish instances. To start the database, open a command prompt, navigate to GF installation directory, change directory to bin, and type asadmin start-database
This will start Derby independent of GlassFish, meaning if GlassFish is stopped or killed, the database server will still be running. All the files related to the Derby are created under the databases folder in your GlassFish installation.
Install and Configure Two or More GlassFish Instances
Install GlassFish on two separate machines. This will avoid port conflicts. In reality too you would need to install GlassFish on two separate machines to achieve high availability. In the event that one instance (and therefore, the IEP SE installed on that instance) fails, the running IEP processes will be failed over to the other instance.Once you have installed GlassFish on two machines, you will need to configure each one of them. Start one of the GlassFish instances and login to the admin console using http://{host1}:4848.
Create connection pools and JDBC resources for IEP SE
Follow these instructions
to create the required connection pools and JDBC resources.
If you are using Oracle, then follow these instructions.
Specify JVM options required by IEP HA
Specify the JVM options as shown here
. Restart GlassFish.
Install IEP SE and other components
Using the admin console, install the required shared libraries, binding components and IEP SE. For the sample application you will need Sun Encoder Library, File BC and IEP SE. If you don't already have the components, the latest version can be downloaded from here. When installing IEP SE, accept the defaults in you have created the JDBC resources with names as suggested in the instructions. Otherwise, change those values appropriately.
Do the above three steps for the second GlassFish instance. Make sure to specify a different value for the JVM option com.sun.jbi.iepse.instanceName (use instance2 for this example).
Your setup is complete. Follow the steps in the next section to run the sample application.
Deploy Sample Application and Test
The sample application
We will use a simple IEP application to test the cluster setup - TupleBasedAvgCalculator. The application is fed events via HTTP. The event contains a simple number. The process has a tuple based aggregator which takes 10 events and calculates its average. It then writes this average to the file system. We will deploy this application on both the GlassFish instances. This means that there are two HTTP endpoints on which the application will listen for events. Events can be sent to both these endpoints directly or by configuring an HTTP Load Balancer. The HTTP BC on each of the two GlassFish instances will forward the event to the IEP SE in corresponding GlassFish instance. Each such IEP SE instance will insert the event into the IEP database. From this point onwards, only one IEP SE instance will "own" and process the event. It also follows that the output will only be written by the IEP SE which owns the instance. In the event that the IEP SE that currently owns the process fails, then other live IEP SE instances will compete to take the ownership of the process. Only one of such live instances will succeed in taking the ownership. This will be clearer as we walk through the example.Deploy sample application
Using the admin console, deploy the sample application on both the instances of GlassFish. The application can be downloaded from here.
Verify that the application is deployed properly
Download the application project files and open the projects TupleBasedAvgCalculator and TupleBasedAvgCalculatorApp in NetBeans. Open the file TupleBasedAvgCalculatorProcess.wsdl. Locate the following line
<soap:address location="http://localhost:${HttpDefaultPort}/service/TupleBasedAvgCalculatorProcess_iep"/>
This is the address to which the events (SOAP messages) will be sent. However, the token ${HttpDefaultPort} will need to be replaced by actual port numbers. Usually the default is 9080.
To make sure that the application is deployed correctly on both the instances, try to access the published WSDLs as follows, by entering in the web browser
http://{host1}:9080/service/TupleBasedAvgCalculatorProcess_iep?wsdl AND
http://{host2}:9080/service/TupleBasedAvgCalculatorProcess_iep?wsdl
Test the Application in HA and Failover Mode
You need a SOAP client like SOAP UI to send messages to the application. We will assume that you are using SOAP UI (the steps will be similar for other clients).Create a new project and import the above two WSDLs in the SOAP UI. Create two Requests, one for each Request. A sample XML message is generated for each Request. Specify an integer value for the element named number in each of the two Requests. Send five messages from each of the two Requests. This means that we are sending events to both the instances. However, the processing would be done only by one instance and consequently, the output will be written to the file by that instance. Open TupleBasedAvgCalculatorProcess.wsdl, and locate the lines
<port name="OutputPort_StreamOutput0" binding="tns:OutputBinding_StreamOutput0">
<file:address fileDirectory="TupleBasedAvgCalculatorProcess_iep"/>
</port>
Here the file path is relative, so the output file will be generated relative to the instance which is doing the processing. Search for a directory under name "TupleBasedAvgCalculatorProcess_iep" under the GlassFish installation directory of both the machines. You should only find it in one of the two GlassFish instances. This means, the IEP SE on that GlassFish instance owns the IEP process. Under the folder, you should see a file named StreamOutput0.txt. Verify that the average is correct.
Note: if you do not see the directory or the file, try sending another message from the SOAP UI.
Now, let us kill the GlassFish instance that owns the process, to see whether the IEP process fails-over to the other live instance. First send three messages from each of the two Requests. Then use your OS's command to kill the GlassFish instance that has the IEP SE that owns the process. Now send another 4 messages to the GlassFish that is still alive. Search for a directory named "TupleBasedAvgCalculatorProcess_iep" under the GlassFish instance that is alive. You should see the file StreamOutput0.txt inside it with the correct average value. The StreamOutput0.txt file under other GlassFish instance should remain unchanged. This means that IEP instance from the alive GlassFish has taken over the ownership of the IEP process. This shows that the IEP High Availability and Failover works!
|
JSPWiki v2.4.100
|
![[RSS]](http://wiki.open-esb.java.net/images/xml.png "Aggregate the RSS feed")
|