Tomcat 7 with mod_jk

Question

I am at cross roads in deciding whether to use mod_jk or mod_proxy for setting up a load balancing system with Apache 2 and Tomcat 7. I read the usual comparison that mod_jk is more powerful but harder to configure, etc. but all that I read is a bit dated (2007-2010) and based on my current requirement I can go either way.

Now looking at Tomcat 7 documentation on connectors! I see that they are essentially deprecating everything except mod_proxy:

Other native connectors supporting AJP may work, but are no longer supported.

So does this mean new uses should go with mod_proxy?

Answer 1

Over the years there have been a number of connectors developed to enable Apache httpd to communicate with Tomcat that have used a variety of protocols. When searching the web for information on how to do this, it isn't unusual to stumble across some really bad, out of date advice. So first of all the only options you should consider for this are:

• mod_jk
• mod_proxy_http
• mod_proxy_ajp

All of the other other options have not been supported for a number of years so you should avoid mod_jk2, mod_jserv, mod_webapp and any other module that isn't discussed here. There three above all are currently supported and are all actively developed.

My experience with providing support to customers at $work is that these days a typical customer is no more likely to hit a bug in mod_proxy_ajp than they are in mod_jk or mod_proxy_http. (A few years ago mod_proxy_ajp wasn't as mature but these days I don't see any difference.)

That brings us to the crunch question: HTTP (mod_proxy_http) or AJP (mod_proxy_ajp or mod_jk)? And the answer? It depends! Both protocols have their strengths and weaknesses. Which one is right for you will depend on your circumstances. The factors that normally affect this choice are:

• Is one protocol / module already in use?
• Does the communication between httpd and Tomcat need to be encrypted?
• Does httpd terminal SSL but the SSL information needs to be passed to Tomcat?

If you are already using mod_jk, mod_proxy_http or mod_proxy_ajp and it meets all of your requirements then there is unlikely to be a good reason to change it. It would be better to stick to what you are currently using and to have consistency across your httpd instances.

If you need to encrypt the communication between httpd and Tomcat then this is significantly easier with mod_proxy_http as you can just switch from the http to the https protocol. mod_jk and mod_proxy_ajp use the AJP protocol which doesn't support encryption so you have to implement that separately via an SSH tunnel, IPSec or similar. This can add significant configuration complexity to the httpd-Tomcat communication channel.

Where httpd terminates the SSL, providing the SSL attributes are exposed (two simple directives) then mod_jk and mod_proxy_ajp automatically pass this information to Tomcat and Tomcat makes it available to web applications without any additional configuration required. To achieve the same result with mod_proxy_http requires httpd to be configured to add the SSL information as http headers and a Valve needs to be configured in Tomcat to extract this information and to make it available to web applications. Making SSL information available to Tomcat is therefore a little more complicated with mod_proxy_http.

mod_jk and mod_proxy_* also have very different configuration styles. The mod_proxy_* directives are consistent with other httpd directives whereas mod_jk uses an external property file. For system administrators familiar with httpd, the mod_jk approach can look a little odd.

In summary:

• If you need to encrypt the httpd to Tomcat channel, use mod_proxy_http
• If you need to expose SSL information to your web application, use mod_jk or mod_proxy_ajp
• If you are already using one of these modules then changing is likely to cause more hassle than it saves
• Given a completely free choice, I'd use mod_proxy_http just because the configuration is more consistent with other httpd modules, it is marginally easier to debug with Wireshark and it can use your existing HTTP connectors in Tomcat.

See also a presentation I wrote (http://people.apache.org/~markt/presentations/2012-10-Apache-Tomcat-Reverse-proxies.pdf) and Rainer Jung's additional comments on that presentation (http://people.apache.org/~markt/presentations/2012-10-Apache-Tomcat-Reverse-proxies-notes-rjung.txt)

Answer 2

mod_proxy is the Apache HTTP server module, not an Apache Tomcat module.

What this page is saying is that Tomcat supports either JK1.2 or the AJP protocol provided by the mod_proxy module within Apache HTTP.

Historically what you had to do was use mod_jk to provide AJP1.3 support to the Apache HTTP server, as of Apache HTTP 2.2 this is now provided within the mod_proxy module - see http://httpd.apache.org/docs/2.2/mod/mod_proxy.html which states:

This module implements a proxy/gateway for Apache. It implements proxying capability for AJP13 (Apache JServe Protocol version 1.3), FTP, CONNECT (for SSL), HTTP/0.9, HTTP/1.0, and HTTP/1.1.

This gives you a couple of choices:

1. Use the HTTP connector within Tomcat and have end-clients connect directly to this.
2. Use the HTTP connector within Tomcat and proxy this via the HTTP mod_proxy HTTP proxy functionality.
3. Use the AJP1.3 connector within Tomcat and proxy this via the HTTP mod_proxy AJP proxy functionality.
4. Use the AJP1.2 connector within Tomcat and connect to this using the HTTP mod_jk AJP module within Apache.

My recommendation would be to go with option 3.

The specific page with information about configuring this within Apache is http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html