Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.
The "FAQ/Connectors" page has been changed by ChristopherSchultz: http://wiki.apache.org/tomcat/FAQ/Connectors?action=diff&rev1=13&rev2=14 Comment: Re-arranged "Which Connector" question and added some additional information. <<BR>> - <<Anchor(Q2)>>'''Which connector: mod_jserv, JK, JK2, mod_webapp or mod_proxy?''' + <<Anchor(Q2)>>'''Which connector: mod_jk or mod_proxy?''' + * mod_jk is mature, stable and extremely flexible. It is under active development by members of the Tomcat community. + * mod_proxy_ajp is distributed with Apache httpd 2.2 and later. Note that the communication protocol used is AJP. + * mod_proxy_http is a cheap way to proxy without the hassles of configuring JK. If you don't need some of the features of mod_jk, this is a very simple alternative. Note that the communication protocol used is HTTP. + + Here are some anecdotal comments from members of the Tomcat community: + + '' + I have been using mod_jk for a very long time and I saw (at the time) + only one reason to make the switch to mod_proxy_ajp: it is bundled + with Apache and so you (likely) don't have to build the module yourself. + + That said, simple configurations are *way* more simple in + mod_proxy_ajp than with mod_jk, although the (somewhat) recent + addition of JkWorkerProperty and JkMount "extensions" do help quite a bit. + + mod_proxy_ajp can also be trivially swapped-out with mod_proxy_http + just by changing the URLs in your ProxyPass and ProxyPassReverse + directives to say http:// (or https://) instead of ajp://. This might + help you if you need to switch protocols for debugging purposes or if + you suddenly need switch to HTTPS to secure the traffic without any + external configuration (e.g. stunnel or VPN). + + mod_proxy also supports ProxyPassMatch which lets you use regular + expressions in your URL mappings, which mod_jk's JkMount does not + (though you *can* use <LocationMatch> along with SetHandler in order + to achieve the same result, it's a cleaner configuration with mod_proxy). + + That said, I have found that mod_jk supports more complicated + configurations where I have struggled to get mod_proxy_ajp to do the + same. Specifically, overlapping URL spaces that must be mapped to + separate workers. Technically speaking, I suppose you could use lots + of ProxyPassMatch directives and/or have a complex regular expression + to direct the various URLs, but again you end up with a rather messy + configuration that way. Messy configurations are a maintenance risk as + well as at risk of becoming "arcane knowledge" that nobody actually + understands and so they are afraid to modify it for any reason. + + Generally, mod_jk will get fixed faster than mod_proxy_ajp due to its + independent release cycle: the httpd folks might have a fix for a + problem but it doesn't get released for a while due to testing of + other components, etc. At this point, mod_proxy_ajp has (IMHO) reached + a point of stability that this is less of an issue than it used to be. + + At this stage, there is no reason for me to move any of my projects + from mod_jk to mod_proxy_ajp but if I were starting from scratch, I + might choose mod_proxy_ajp solely due to its binary availability and + simple configuration. If the configuration became complicated to the + extent that switching to mod_jk were a good option, then I'd move. + + As for performance, I have no data on that one way or another. I would + suspect that mod_jk has a slight performance advantage because it has + been especially designed for the purpose rather than mod_proxy_ajp + which must support the mod_proxy API and might have a bit more + plumbing code to accomplish that. I would be surprised if you could + detect any performance difference between the two if you were to test + them both faithfully and with compatible configurations. If anyone has + relative performance data between mod_jk and mod_proxy_ajp, I'd be + happy to read it. + '' + (http://markmail.org/message/u5v4aiejluzy7tde) + <<BR>> + + <<Anchor(Q2.1)>>'''What about mod_jserv, mod_jk2, mod_webapp (aka warp)?''' + + '''All of these connectors have been abandoned long ago. Do not use any of them.''' + + mod_jk2 sounds like it could be an updated version of mod_jk, it is not: it was an abortive effort whose features have been re-incorporated into mod_jk. + + For historical purposes, and emphasis: + + * mod_jserv is unsupported and will not be supported in Tomcat 5 onward. mod_jserv was the original connector which supported the ajp protocol. '''Do not use mod_jserv.''' * Stay away from mod_webapp, aka warp. It is deprecated and unsupported due to lack of developer interest and there are better options such as jk and mod_proxy. It WILL NOT run on windows. '''Do not use mod_webapp or warp.''' - * mod_jserv is unsupported and will not be supported in Tomcat 5. mod_jserv was the original connector which supported the ajp protocol. '''Do not use mod_jserv.''' - * jk2 is a refactoring of mod_jk and uses the Apache Portable Runtime (apr). But due to lack of developer interest, it is unsupported. The alternative is mod_jk or mod_proxy_ajp. '''Do not use jk2.''' + * jk2 is a refactoring of mod_jk and uses the Apache Portable Runtime (apr). But due to lack of developer interest, it is unsupported. '''Do not use mod_jk2.''' - * '''mod_jk is mature, stable and extremely flexible.'''. It is under active development by members of the Tomcat community. - * mod_proxy. A cheap way to proxy without the hassles of configuring JK. If you don't need some of the features of jk - this is a very simple alternative. - * mod_proxy_ajp. With apache 2.2, mod_proxy was rewritten to support load balancing as well as a new transport called mod_proxy_ajp. This module is distributed with the Apache http server, not the Tomcat server. - <<BR>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
