tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat)>
Subject Re: Creating another Tomcat copy in hot stand-by when original goes down.
Date Tue, 08 Dec 2015 17:35:53 GMT
On 08.12.2015 14:07, Kernel freak wrote:
> Hello friends,
> I am working on a Debian server in which I would like to setup 2 instances
> of Apache tomcat which will be load balanced by an Apache HTTP server(Do I
> require a http server? ). In-case one copy of Apache tomcat goes down, the
> other one will automatically comes online.
> While I was creating a configuration for one of our server, I know how to
> relay requests based upon URL to Apache Tomcat, these are the 2 things I
> don't know.
> 1) Will this work with https? Reason I ask is, there are many pages which
> are served under https and the configuration which I have and shown below
> seems to be calling with http instead of https.
> 2) How to trigger the 2nd copy of tomcat.

Hi. To answer this "top-down" :

1) to do "load-balance" 2 tomcats, there are many ways, and you do not necessarily have to

use Apache httpd as a front-end, there are other solutions.
But the Apache httpd solution is probably the easiest to set up, and it's free.

2) picture the following setup :

user browser <-- HTTP or HTTPS --> Apache httpd <-- HTTP/HTTPS/AJP --> tomcat1
                                     + Connector <-- HTTP/HTTPS/AJP --> tomcat2

tomcat1 and tomcat2 are always active, both.  You do not start one when the other fails.
They are normally both active, and they share the load (the httpd Connector does that for

If one tomcat fails, the Connector under Apache httpd will notice that, and will start 
forwarding the requests only to the still-working tomcat.
When the failed tomcat comes back on-line, the Connector notices again, and starts 
balancing the requests again to both tomcats.
If both tomcats fail, you get an error at the httpd level.

3) for the httpd-level "Connector" between httpd and tomcat, you have 3 choices :
    a) mod_proxy + mod_proxy_http
    b) mod_proxy + mod_proxy_ajp
    c) mod_jk
Each one of those can do load-balancing, but their configuration is different.

4) If Apache httpd and the tomcats communicate through a network that is considered as 
secure, then the most efficient configuration would be :

                 Connection A                       Connection B
user browser <-- HTTP or HTTPS --> Apache httpd <-- HTTP/AJP --> tomcat1
                                     + Connector <-- HTTP/AJP --> tomcat2

The usual way of describing this is "terminating HTTPS at the httpd level".
In other words, do not use HTTPS between httpd and tomcat (connection B), because it would

unnecessarily force an additional encryption/decryption.
All the additional HTTPS information that may be needed at the tomcat level, to know that

the original user connection with httpd (connection A) was under HTTPS, will be anyway 
forwarded by the Connector, to Tomcat (as HTTP request headers).
(So tomcat can always know if the original browser to httpd connection A was secure or not.)

- The (mod_proxy + mod_proxy_http) Connector, forwards the original (HTTP/HTTPS) client 
requests to Tomcat, using the HTTP protocol (and format).
So at the receiving end, in Tomcat, you need a matching HTTP Connector.

- the (mod_proxy + mod_proxy_ajp) Connector, and the mod_jk Connector, forward the 
original (HTTP/HTTPS) client requests to Tomcat, using a protocol/format that is not HTTP,

but which essentially carries the same information (it is the AJP protocol/format).
So at the receiving end you need a matching AJP Connector.

- when the request is received by Tomcat using either one of the Tomcat Connectors, it is

the job of the Tomcat-side Connector to "translate" this request into an internal Tomcat 
"request object", which is always the same.  So from the point of view of your tomcat 
webapps, it does not matter through which Connector the request was received, it always 
looks the same.

- one difference between proxying through HTTP and proxying through AJP, is that the AJP 
protocol does not have a corresponding "AJPS" encrypted version.
In other words, you should probably not use either (mod_proxy + mod_proxy_ajp) or mod_jk,

if your httpd and tomcats communicate over a non-secure channel (such as over an Internet

connection). (You could still do that over an SSH tunnel, but that complicates things).

- another difference is that the AJP protocol can carry to tomcat, a user-id that has been

authenticated at the httpd level.  The HTTP protocol does not do that by itself.
(In short, if you authenticate users at the httpd level, and want Tomcat to use this and 
avoid authenticating the user again, then use the AJP protocol).

Does this give you enough material to figure out the rest of your questions ?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message