Configuring for Resilience

PhixFlow con be configured as a multiple-instance cluster in which at any one time, one instance is the main, active  instance and the other instance(s) serve as hot standbys – if the main instance fails, one of the standby instances will automatically take over as the active instance.

 The different instances must run on separate Java virtual machines, and will generally run on separate physical servers.

All instances are live, and are connected to the same database and the same file share (for file collection), but only one of them is active any one time.

A proxy web server knows which is the currently active instance, and routes traffic between the user’s web browser and the currently active instance. When the proxy web server detects that the active instance is taking too long to respond, it signals the standby instance to take over and starts to route traffic to the standby server.

Responsibilities of the Proxy Web Server

The proxy web server is a third-party component, and has a number of responsibilities:

a)      It routes traffic between the user’s web browser and the active instance

b)     It must periodically poll the servers to see which are active – a ‘ping’ web call is provided specifically for this purpose.

c)      When the main instance fails to respond to the ping request, the proxy must poll all servers until one of the standby servers responds, indicating that it has become the active server.

Configuring a resilient instance

A resilient PhixFlow configuration consists of 2 or more web applications all connected to a common database and configured such that at any one time, only one is active; the other instances will monitor the first and one will take over if they detect that the first has failed.

In such a configuration, set the instance name and id for each PhixFlow webapp instance to unique values and set leaderOnStartup to “true” for an instance if it should become active immediately on startup.

When configuring instances in a resilient configuration, edit the phixflow-instance.xml file for each instance so that

a)      Each instance has a unique instance name and id

b)     The main instance has leaderOnStartup set to true, and the standby instance has it set to false.

Each phixflow-instance.xml should look something like this:

<!-- The instance name must be different for each member of the cluster -->
<bean id="clusterInstance"
	class="com.accipia.phixflow.service.cluster.main.ClusterInstance"
	p:name="MAIN"
	p:id=”1”
	p:leaderOnStartup="true"
/>

If no instance has leaderOnStartup set to true, one of the standby servers will become active after a timeout period..

Web service calls

Each PhixFlow instance supports the following web service calls which may be used in support of a resilient configuration.

Ping an instance

The PhixFlow instance will generate a simple response immediately if it is the active instance; if not, it will respond after a long delay.

http://server/phixflow/ping.htm