1. Introduction

However, as the Java Virtual Machines become faster over years, people tend to ask for always more personnalized and dynamic contents, and this type of application requires always more and more CPU power. Apache JServ addresses this requirement and lets you distribute your application load over as many hosts as needed.

At the same time, applications and user transactions are based on HTTP sessions, and Apache JServ ensures that the system will take care of them. Of course the whole system has to be fault-tolerant.

And of course all for free ... ;-)

This document describes how to use Apache JServ load-balancing and fault tolerance features.

Thank you for using Apache JServ.
 
 [...]

3.6 Fault tolerance

3.6.1 No single point of failure

If you have more than one Apache host, one of them can stop, and the system will still work (modulo SSL sessions for https servers).
It is up to you to provide a load-balancing/fail-over mechanism (round-robin DNS or dedicated hardware) to be able to use fail-over on Apache. (But we ensure that user sessions will survive a Apache crash).

If you have more than one JServ host, one of them can stop, and the system will still work. (modulo broken sessions).

Any Apache is able to route a request to any JServ. (session are  maintained, does not rely on any of the following elements : load-balancer hardware, or Apache server).
As long as you have one Apache and one JServ running, the system can work.

Fault-tolerance is implicit if load-balancing is enabled for this zone.
All our httpd processed share a memory zone, which contains the last known status for every JServ.
As soon as a JServ is marked "unavailable" by one httpd process, the information is accessible by other processes on the same host. This prevents repetitive connect failures or even TCP connect timeouts.
The request & following requests will be redirected to others JServ in the same "set" of JServs.
A watchdog program will run silently, and try to connect to this JServ until success. Once succeeded, the JServ will be accessed again by httpd processes.
The session is broken if a request is redirected to another JServ. The existing one is considered invalid, as sessions can not travel across the network (not in Servlet API specs).
 

3.6.2. Scenario 1: Apache fault-tolerance


We have 2 Apache servers on 2 different hosts.
1 - first step
a. Web client requests a page from www.jserv.com, port 80
b. www.jserv.com is a load-balancing system which actually resolves the request to go to server Httpd server 111.222.333.10, port 3000.
c. The Apache Httpd server listening on 111.222.333.10, port 3000 chooses (at random) a Jserv machine, 192.168.0.51, port 8885, to handle the request.
d. The Jserv machine at 192.168.0.51, port 8885 responds to the request with the content of the page along with a cookie with name JServSessionID and value "xxxx-JS1".

2 - second step
a. Web client requests another page from www.jserv.com, port 80
b. www.jserv.com resolves to 111.222.333.20, port 3000 (a different machine from last hit time).
c. The Apache server recognizes the JServSessionID cookie and looks at the Jserv identifier, "JS1" at the end of the cookie.
d. The Apache server sees that JS1 is the identifier for 192.168.0.51, port 8885, and passes the request to that same server.