Hi.
Let me just add a bit to Daniel's outline below.
vi...@thepenguin.org wrote:
Hi Daniel:
I appreciate your reply and apologize for the top post (am using a stupid mail
client from work). Your answer gets me part way there, but what is the most
confusing to me is the use of JkMount. How does that fit into the picture from
a communication perspective. I hope this question is clear, but since my Google
searches are not turning up anything, I fear that it won't be.
Thanks,
CaptainVic
-----Original Message-----
From: "Daniel Mikusa" <dmik...@vmware.com>
Sent: Wednesday, January 9, 2013 8:28am
To: "Tomcat Users List" <users@tomcat.apache.org>
Subject: Re: Communication flow with different connectors
On Jan 9, 2013, at 7:31 AM, vi...@thepenguin.org wrote:
Hello:
I am seeking to understand the differences between using mod_jk and mod_ajp and
mod_proxy_ajp.
This is a good article that explains the different ways to proxy to an Apache
HTTPD server. It's a little old, but still good.
http://www.tomcatexpert.com/blog/2010/06/16/deciding-between-modjk-modproxyhttp-and-modproxyajp
Ideally I would love to see a diagram of communication between apache and
tomcat, but I haven't found anything like that. I want to confirm my
understanding of the data flow.
Not quite sure what you mean by this, gonna take a couple guesses...
1.) If you are looking for an explanation of how a request travels from a
client to Tomcat, then this might help.
When using mod_jk or mod_proxy_ajp, traffic flows from the client to Tocmat
like this...
client -> HTTP(s) -> Apache HTTPD -> AJP -> Tomcat
then from Tomcat back to the client over the same path.
If using mod_proxy_http, it is similar but looks like this.
client -> HTTP(s) -> Apache HTTPD -> HTTP(s) -> Tomcat
then from Tomcat back to the client over the same path.
To expand a bit the above :
If we limit ourselves to the AJP protocol,
- on the Tomcat side, there is only one AJP Connector, and the communication protocol is
always the same.
- on the httpd side, the options are :
a)
client -> HTTP(s) -> (Apache HTTPD + mod_proxy + mod_proxy_ajp) -> AJP ->
Tomcat
or
b)
client -> HTTP(s) -> (Apache HTTPD + mod_jk) -> AJP -> Tomcat
Which one you choose is mainly a matter of needs, convenience and preferences, as
explained here : http://wiki.apache.org/tomcat/FAQ/Connectors
About "JkMount" etc :
In the Apache httpd configuration context, the "JkMount" syntax and usage is sometimes a
bit awkward, because it does not follow the general pattern of other httpd configuration
directives, and it is not very clear where in the Apache request processing cycle it
intervenes.
But instead of JkMount/JkUnMount, there exists another mod_jk configuration possibility,
which is explained at the bottom of this page :
http://tomcat.apache.org/connectors-doc/reference/apache.html
(see the section : Using SetHandler and Environment Variables)
I find that configuring mod_jk in this way makes it easier to understand the way in which
it works. And it also allows you to use mod_jk in conjunction with other standard Apache
httpd configuration options, such as Alias, RewriteRule etc.
(JkMount/JkUnMount are a bit more obscure in terms of how they interplay with other httpd
configuration snippets).
For Apache httpd, mod_jk is a "response handler", which generates the response to a HTTP
request. After Apache has analysed the incoming HTTP request and mapped it to the
appropriate <Location> section, it hands the request to the configured response handler
for that section, and expects in return a response document (or an error) to pass back to
the client browser.
In this case, that response handler is "jakarta-servlet" (an alias for mod_jk).
Apache httpd basically has no idea that when it asks mod_jk to generate the response to a
request, mod_jk in the background is communicating with one or more back-end Tomcat
servers which do the real work.
(And the details of how mod_jk is doing this, are in the separate mod_jk configuration
file "workers.properties").
Does this help ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
