Why the switch to mod_proxy from mod_jk?

I've talked about this a lot in various places, but because I expect to get a few questions about this, I want to create a post where I could fully explain the decision to move from mod_jk to mod_proxy. As of Version 4 of the Railo Installer, mod_proxy_http will be configured by default in Linux Apache installations.

Current Installs Will Continue to Function

If you're comfortable using mod_jk, then there's no reason for you to migrate any of your existing installation to mod_proxy. mod_jk will continue to work just fine with Railo and Tomcat for as long as the Tomcat developer community continues to develop and improve mod_jk. There is no reason to switch if you're comfortable where you are.

Mod_proxy is Simpler to Configure

There are sevaral points to make within this overall "mod_proxy is simpler" point. First, it should be noted that mod_proxy is installed by default in nearly all modern Apache installs. Even Windows version. So as far as "installing" mod_proxy goes, it's incredibly easy because in most cases it's already there! Second, mod_proxy is configured purely by a few commands within the Apache configuration file. Mod_jk has several different configuration files you have to work with. These additional files are the cause for much confusion among users about what to edit, when to change it, and what to change it to in order to do what you want. Once you know the purpose of each file for mod_jk, it's really not very difficult, but it can be daunting to try to figure it out, or if you're on an unfamiliar system, find where those specific files are located. With mod_proxy, you can simply look at the proxy rules, and generally have a pretty good idea of what's going on without having to track down and review separate configuration files.

Mod_proxy is Recommended by Tomcat Dev Team

This article describes in detail the differences between the current connection methods: http://www.tomcatexpert.com/blog/2010/06/16/deciding-between-modjk-modproxyhttp-and-modproxyajp

Note that the article was written by Mark Thomas, a member of the Apache Foundation and Tomcat Developer.

Mod_proxy Fits Better into Future of CFML

There are many features that would be very useful when connecting Apache to Tomcat with regards to the CFML development language. For example, it would be nice if users could have some built-in support for Search Engine Safe URL's without having to add complex mappings to their Apache configurations. It would also be nice to have the ability for Apache to pass on certain aspects of its configuration to Tomcat from within the HTTP protocol. Work in that area has started with the mod_cfml project, but it would be great if mod_cfml could run as a native Apache module instead of as a mod_perl module. Mod_perl is fantastic software, but some users resent having to install it in order to get mod_cfml working in Apache.

With mod_proxy, we can extend mod_proxy's existing functionality and add our own - in much the same way that mod_proxy_ajp and mod_proxy_html extend the base functionality of mod_proxy, we could potentially create a mod_cfml module that is simply an extension of mod_proxy where basic support for CFML pass-throughs are built in directly to the module. This would make installation and configuration even easier then it is currently.

Comments

1
Federick Kwok

Hi Jordan, Thanks for the post. I was so confused when I installed Railo 4 and found all the mod_proxy stuff since just 6 months ago when I installed Railo 3.3, it was mod_jk. I really wasn't sure which one I should go with since they both seems to work :p Anyway, I just have one question, using mod_proxy, can I still have non CFML sites running on the same server? Will Apache forward everything over to Tomcat? Thanks in advance. Cheers Federick

2
jordan

Hi Fredrick, Yep! Mod_proxy will do pretty much everything mod_jk will do, even load balancing! It also works better then mod_jk in heterogeneous environments, so if you want to run a wordpress right next to your mura site, it is supported right out of the box! You shouldn't have to change anything about your install in order to support it. Hope this helps!

3
Rory

Hi Jordan, something that tripped us up with the change was needing to update Tomcat's server.xml to include the RemoteIP valve, which uses the x-forwarded-for from mod_proxy to retain the users remoteIP. Without it, cgi.remote_addr in Railo shows as localhost. Is that something that would best be setup with the installer by default? Maybe we had a bad config (lots of custom changes that may have deleted this), but I would assume most users would expect the remoteIP address by default? Documentation: https://code.google.com/p/xebia-france/wiki/RemoteIpValve

4
Jonathan van Zuijlekom

Why not use mod_proxy_ajp? The blog post your linking here is 3 years old. With mod_proxy_ajp you get SSL and remote ip information out of the box and performance is a bit better.

5
jordan

@Jonathan Because mod_proxy_ajp isn't readily available. In some distributions, you need to custom compile it in order to add it at all. Mod_proxy_http is far more readily accessible, and the performance benefits are small and subjective to the content. If the situation changes with mod_proxy_ajp, then yeah, we can revisit it. Personally, I'd rather we just write our own connector,but that takes some time.

Write your comment

(it will not be displayed)

Leave this field empty: