[Tomcat Wiki] Update of "FAQ/Connectors" by ChristopherSchultz

[Apache Wiki <wi...@apache.org>]

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org