Options for connecting [[Apache|Apache httpd]] to the [[Tomcat]] Servlet/JSP engine

[[Tomcat|Apache Tomcat]] Tomcat is perfectly capable of serving standing on its own as a [[httpd|HTTP/HTTPS server]], reasonable HTTP/HTTPS server, but [[Apache|Apache httpd]] can be used sometimes you want to use Apache httpd as the front end for client requests as well. Listed requests. There are lots of reasons that you may want to do this, and there's really no reason to cover them here. What follows is a primer on the most popular options for establishing this integration.

Options for and useful ways of connecting Apache httpd to Tomcat's Servlet/JSP engine

* [[mod_proxy]]

* [[mod_jk]]

* [[mod_proxy_ajp]]

Each of these choices has its advantages and disadvantages. Tomcat, in no particular order. Detailed configuration research is left as an exercise for the reader.

h2. Use httpd mod_proxy and ProxyPass/ProxyReverse

httpd mod_proxy and ProxyPass/ProxyReverse This is a quick probably the quickest and easy easiest way to connect httpd to Tomcat, but it is also the least flexible and least performant. Complex Some pretty complex configurations can be created with mod_proxy and the associated mod_proxy_* modules, however but it's probably not the best solution worth your time to explore this option unless:

* There is You only have one Tomcat back-end instance

* All that matters is You want the quickest possible time to setup

* Using Apache You can't use httpd 2.2.x is not an option

* Performance You don't have high performance requirements are not a concern

* There is a preference to You're not compile comfortable compiling httpd modules from source

One advantage A plus with this method is that if proxying you are proxy-ing with plain http (not https), you can use tools like [[snort]] snort or [[tcpdump]] can tcpdump to view the conversation back and forth. This can be useful for Kinda handy if you're troubleshooting issues.

*Bottom line:* Bottom line: useful only in limited circumstances, and not a good choice for high-volume or business-critical installations.

h2. Use Tomcat mod_jk (Apache 1.3 and greater)

The Tomcat mod_jk httpd module has gone through a long cycle of development and improvements. It's been around for quite some time and is reasonably stable. This module talks to Tomcat using the [[AJP13]] AJP13 protocol, which is a packet-oriented binary protocol. Using AJP13 has pretty significant performance advantages in that it supports connection persistence, and it implements a form of payload compression to reduce the amount of data traversing the connection. It also has built-in support for handling multiple back-end servers.

Although Using mod_jk is generally stable and performant, it may or may not be the best option. a simple slam-dunk however. To properly implement mod_jk generally requires doing some code compilation, compilation on your own, and there are configuration factors that must match up on both the httpd and Tomcat side. With those caveats, mastery of That said, once you've mastered the vagaries of mod_jk configuration will enable you'll be able to set up a robust and performant multi-server installation.

You should use mod_jk is the best solution for Apache/Tomcat integration if:

* Higher You need higher performance than that plain mod_proxy is needed can provide

* Support for You need to support multiple back-ends with failover and/or session stickyness is needed

* Extra You don't mind the extra effort of compiling your own httpd modules is not a factor

*Bottom line:* Bottom line: most shops will choose this option, as it's a the most heavily used and tested solution that provides redundancy features.

h2. Use http mod_proxy/mod_proxy_ajp/mod_proxy_balancer (httpd 2.2.x and later)

As of Apache httpd 2.2.x there is native support for the AJP13 protocol available without having to compile your own mod_jk. The addition of mod_proxy_ajp and mod_proxy_balancer to the httpd codebase really reduces the number of hoops you have to jump through to get AJP connectivity to Tomcat.

As with mod_jk, combining mod_proxy_ajp/_balancer allows for complex configurations with multiple back-ends, session stickyness and automatic failover (though failover/failback may still be slightly iffy). There is still a need to make specific configuration changes on the Tomcat side, but they are essentially the same as you would make for mod_jk integration.

You should use mod_proxy_ajp/_balancer is the best choice if:

* Using You are comfortable using Apache 2.2.x is not an issue

* Compiling You don't want the hassle of compiling your own mod_jk is an issue

* A You want a 'pure' Apache httpd installation is needed

* Being You can afford to be slightly on the 'bleeding edge' is acceptable (mod_proxy_ajp is not as mature as mod_jk)

*Bottom line:* mod_proxy_ajp Bottom line: this is a clean cleaner implementation that comes with Apache 2.2.x, in my opinion, but since I'd want to really test it is relatively newer, out before going whole-hog with a production site. In the long run it may require more testing than the other choices. With time, turn out that this native implementation of AJP13 should become becomes the favored one, with mod_jk becoming vestigial.

h1. Options for connecting [[Apache|Apache httpd]] Apache httpd to the [[Tomcat]] Tomcat Servlet/JSP engine

Tomcat is perfectly capable of standing on its own as a reasonable HTTP/HTTPS server, but sometimes you want to use Apache httpd as the front end for client requests. There are lots of reasons that you may want to do this, and there's really no reason to cover them here. What follows is a primer on the most popular and useful ways of connecting httpd to Tomcat, in no particular order. Detailed configuration research is left as an exercise for the reader.

h2. Use httpd mod_proxy and ProxyPass/ProxyReverse

This is probably the quickest and easiest way to connect httpd to Tomcat, but it is also the least flexible and least performant. Some pretty complex configurations can be created with mod_proxy and the associated mod_proxy_* modules, but it's probably not worth your time to explore this option unless:

* You only have one Tomcat back-end instance

* You want the quickest possible time to setup

* You can't use httpd 2.2.x

* You don't have high performance requirements

* You're not comfortable compiling httpd modules

A plus with this method is that if you are proxy-ing with plain http (not https), you can use tools like snort or tcpdump to view the conversation back and forth. Kinda handy if you're troubleshooting issues.

Bottom line: useful only in limited circumstances, and not a good choice for high-volume or business-critical installations.

h2. Use Tomcat mod_jk (Apache 1.3 and greater)

The Tomcat mod_jk httpd module has gone through a long cycle of development and improvements. It's been around for quite some time and is reasonably stable. This module talks to Tomcat using the AJP13 protocol, which is a packet-oriented binary protocol. Using AJP13 has pretty significant performance advantages in that it supports connection persistence, and it implements a form of payload compression to reduce the amount of data traversing the connection. It also has built-in support for handling multiple back-end servers.

Using mod_jk is not a simple slam-dunk however. To properly implement mod_jk generally requires doing some code compilation on your own, and there are configuration factors that must match up on both the httpd and Tomcat side. That said, once you've mastered the vagaries of mod_jk configuration you'll be able to set up a robust and performant multi-server installation.

You should use mod_jk if:

* You need higher performance that plain mod_proxy can provide

* You need to support multiple back-ends with failover and/or session stickyness

* You don't mind the extra effort of compiling your own httpd modules

Bottom line: most shops will choose this option, as it's the most heavily used and tested solution that provides redundancy features.

h2. Use http mod_proxy/mod_proxy_ajp/mod_proxy_balancer (httpd 2.2.x and later)

As of Apache httpd 2.2.x there is native support for the AJP13 protocol available without having to compile your own mod_jk. The addition of mod_proxy_ajp and mod_proxy_balancer to the httpd codebase really reduces the number of hoops you have to jump through to get AJP connectivity to Tomcat.

As with mod_jk, combining mod_proxy_ajp/_balancer allows for complex configurations with multiple back-ends, session stickyness and automatic failover (though failover/failback may still be slightly iffy). There is still a need to make specific configuration changes on the Tomcat side, but they are essentially the same as you would make for mod_jk integration.

You should use mod_proxy_ajp/_balancer if:

* You are comfortable using Apache 2.2.x

* You don't want the hassle of compiling your own mod_jk

* You want a 'pure' Apache httpd installation

* You can afford to be slightly on the 'bleeding edge' (mod_proxy_ajp is not as mature as mod_jk)

Bottom line: this is a cleaner implementation in my opinion, but I'd want to really test it out before going whole-hog with a production site. In the long run it may turn out that this implementation of AJP13 becomes the favored one, with mod_jk becoming vestigial.

h1. Options for connecting Apache httpd to the Tomcat Servlet/JSP engine

Tomcat is perfectly capable of standing on its own as a reasonable HTTP/HTTPS server, but sometimes you want to use Apache httpd as the front end for client requests. There are lots of reasons that you may want to do this, and there's really no reason to cover them here. What follows is a primer on the most popular and useful ways of connecting httpd to Tomcat, in no particular order. Detailed configuration research is left as an exercise for the reader.

h2. Use httpd mod_proxy and ProxyPass/ProxyReverse

This is probably the quickest and easiest way to connect httpd to Tomcat, but it is also the least flexible and least performant. Some pretty complex configurations can be created with mod_proxy and the associated mod_proxy_* modules, but it's probably not worth your time to explore this option unless:

* You only have one Tomcat back-end instance

* You want the quickest possible time to setup

* You can't use httpd 2.2.x

* You don't have high performance requirements

* You're not comfortable compiling httpd modules

A plus with this method is that if you are proxy-ing with plain http (not https), you can use tools like snort or tcpdump to view the conversation back and forth. Kinda handy if you're troubleshooting issues.

Bottom line: useful only in limited circumstances, and not a good choice for high-volume or business-critical installations.

h2. Use Tomcat mod_jk (Apache 1.3 and greater)

The Tomcat mod_jk httpd module has gone through a long cycle of development and improvements. It's been around for quite some time and is reasonably stable. This module talks to Tomcat using the AJP13 protocol, which is a packet-oriented binary protocol. Using AJP13 has pretty significant performance advantages in that it supports connection persistence, and it implements a form of payload compression to reduce the amount of data traversing the connection. It also has built-in support for handling multiple back-end servers.

Using mod_jk is not a simple slam-dunk however. To properly implement mod_jk generally requires doing some code compilation on your own, and there are configuration factors that must match up on both the httpd and Tomcat side. That said, once you've mastered the vagaries of mod_jk configuration you'll be able to set up a robust and performant multi-server installation.

You should use mod_jk if:

* You need higher performance that plain mod_proxy can provide

* You need to support multiple back-ends with failover and/or session stickyness

* You don't mind the extra effort of compiling your own httpd modules

Bottom line: most shops will choose this option, as it's the most heavily used and tested solution that provides redundancy features.

h2. Use http mod_proxy/mod_proxy_ajp/mod_proxy_balancer (httpd 2.2.x and later)

As of Apache httpd 2.2.x there is native support for the AJP13 protocol available without having to compile your own mod_jk. The addition of mod_proxy_ajp and mod_proxy_balancer to the httpd codebase really reduces the number of hoops you have to jump through to get AJP connectivity to Tomcat.

As with mod_jk, combining mod_proxy_ajp/_balancer allows for complex configurations with multiple back-ends, session stickyness and automatic failover (though failover/failback may still be slightly iffy). There is still a need to make specific configuration changes on the Tomcat side, but they are essentially the same as you would make for mod_jk integration.

You should use mod_proxy_ajp/_balancer if:

* You are comfortable using Apache 2.2.x

* You don't want the hassle of compiling your own mod_jk

* You want a 'pure' Apache httpd installation

* You can afford to be slightly on the 'bleeding edge' (mod_proxy_ajp is not as mature as mod_jk)

Bottom line: this is a cleaner implementation in my opinion, but I'd want to really test it out before going whole-hog with a production site. In the long run it may turn out that this implementation of AJP13 becomes the favored one, with mod_jk becoming vestigial.

h1. Options for connecting Apache httpd to the Tomcat Servlet/JSP engine

Tomcat is perfectly capable of standing on its own as a reasonable HTTP/HTTPS server, but sometimes you want to use Apache httpd as the front end for client requests. There are lots of reasons that you may want to do this, and there's really no reason to cover them here. What follows is a primer on the most popular and useful ways of connecting httpd to Tomcat, in no particular order. Detailed configuration research is left as an exercise for the reader.

h2. Use httpd mod_proxy and ProxyPass/ProxyReverse

This is probably the quickest and easiest way to connect httpd to Tomcat, but it is also the least flexible and least performant. Some pretty complex configurations can be created with mod_proxy and the associated mod_proxy_* modules, but it's probably not worth your time to explore this option unless:

* You only have one Tomcat back-end instance

* You want the quickest possible time to setup

* You can't use httpd 2.2.x

* You don't have high performance requirements

A plus with this method is that if you are proxy-ing with plain http (not https), you can use tools like snort or tcpdump to view the conversation back and forth. Kinda handy if you're troubleshooting issues.

Bottom line: useful only in limited circumstances, and not a good choice for high-volume or business-critical installations.

h2. Use Tomcat mod_jk (Apache 1.3 and greater)

The Tomcat mod_jk httpd module has gone through a long cycle of development and improvements. It's been around for quite some time and is reasonably stable. This module talks to Tomcat using the AJP13 protocol, which is a packet-oriented binary protocol. Using AJP13 has pretty significant performance advantages in that it supports connection persistence, and it implements a form of payload compression to reduce the amount of data traversing the connection. It also has built-in support for handling multiple back-end servers.

Using mod_jk is not a simple slam-dunk however. To properly implement mod_jk generally requires doing some code compilation on your own, and there are configuration factors that must match up on both the httpd and Tomcat side. That said, once you've mastered the vagaries of mod_jk configuration you'll be able to set up a robust and performant multi-server installation.

You should use mod_jk if:

* You need higher performance that plain mod_proxy can provide

* You need to support multiple back-ends with failover and/or session stickyness

* You don't mind the extra effort of compiling your own httpd modules

Bottom line: most shops will choose this option, as it's the most heavily used and tested solution that provides redundancy features.

h2. Use http mod_proxy/mod_proxy_ajp/mod_proxy_balancer (httpd 2.2.x and later)

As of Apache httpd 2.2.x there is native support for the AJP13 protocol available without having to compile your own mod_jk. The addition of mod_proxy_ajp and mod_proxy_balancer to the httpd codebase really reduces the number of hoops you have to jump through to get AJP connectivity to Tomcat.

As with mod_jk, combining mod_proxy_ajp/_balancer allows for complex configurations with multiple back-ends, session stickyness and automatic failover (though failover/failback may still be slightly iffy). There is still a need to make specific configuration changes on the Tomcat side, but they are essentially the same as you would make for mod_jk integration.

You should use mod_proxy_ajp/_balancer if:

* You are comfortable using Apache 2.2.x

* You don't want the hassle of compiling your own mod_jk

* You want a 'pure' Apache httpd installation

* You can afford to be slightly on the 'bleeding edge' (mod_proxy_ajp is not as mature as mod_jk)

Bottom line: this is a cleaner implementation in my opinion, but I'd want to really test it out before going whole-hog with a production site. In the long run it may turn out that this implementation of AJP13 becomes the favored one, with mod_jk becoming vestigial.