Dave Filchak wrote:
...
Hi.
Since the simple answer did not work (or was not sufficient), and since
on the other hand you seem to be wanting to understand what you are
doing, let me try to give you an overview.
For short, I will use "Apache" when I mean Apache httpd, and Tomcat to
mean the Apache Tomcat servlet engine/container.
You have an Apache server listening on port 80, and processing requests
directed there.
For some of these requests however, you would like Apache to "proxy"
them to a back-end Tomcat server, to be processed there. The result of
that back-end processing should then be returned to Apache, so that
Apache can return them to the browser.
This requires a "connector", both at the Apache side and at the Tomcat
side. That is like a plug on each side, with a wire in-between.
On that wire will circulate the requests that Apache passes to Tomcat,
and the response that Tomcat sends to Apache.
At the Tomcat side, the "plug" is a <Connector> element. This Connector
specifies a port number it will listen to, and a protocol it will use.
Since you started with mod_jk as a connector module at the Apache side,
this port is by default usually set to 8009; the protocol is alway "AJP".
Now the issue is to configure the plug on the Apache side, namely the
mod_jk connector.
mod_jk is a sophisticated animal, which can do a host of things apart
from the simple one we need here : it can talk to multiple Tomcat
back-ends, it can load-balance between them, detect availability and
failures of the back-ends etc..
That is what all these "extra" Jk parameters are all about, which I will
not discuss here since they are already excellently described in the
on-line documentation. Instead, let's stick to the essentials.
Basically, we have to
- tell Apache to load the mod_jk module,
- and then tell mod_jk the following :
- which requests it should "grab" at the Apache level, and pass to Tomcat
- where this Tomcat is, in terms of IP address and port (that is, in
this case, the IP address of the host where Tomcat runs, and the port on
which the Tomcat AJP connector is listening).
To tell Apache to load the mod_jk module, there is an Apache
configuration directive similar to this :
LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so
That's it. The mod_jk module gets initialised, and in the process it
tells Apache which other configuration directives it will handle.
When Apache later finds these in its configuration, it will call mod_jk
to process them.
Next we need these configuration directives, which tell mod_jk what to
do. There are usually the following :
First, tell mod_jk where and what to log :
JkLogFile /var/log/apache2/mod_jk12.log
JkLogLevel info
(That is quite important for debugging. Examining this file will show
you what mod_jk is doing (or not doing), and will usually point to the
problems right away.)
Then, we tell mod_jk in which other configuration file it will find a
description of the Tomcat's it should be talking to :
JkWorkersFile /etc/apache2/workers.properties
(in mod_jk language, these Tomcats are called "workers", hence the name
above)
In that file, we'll for now just use the essentials :
worker.list=anyname
worker.anyname.port=8009
worker.anyname.host=localhost
worker.anyname.type=ajp13
That is really all that's needed if you have a single Tomcat in the
background to talk to.
I purposedly used "anyname" above to indicate that a worker name can be
anything you choose, it does not have to be "worker1" or "ajp13" as
you'll often see in default configurations. But remember the name you
gave this worker, because you'll need it at the next step.
(For more Tomcats, see the comment under (*) below)
Now we have one part left : let Apache know which requests should go to
Tomcat.
In fact, it is not really Apache we are telling this to, it is mod_jk
itself. mod_jk registers itself with Apache as a "content handler".
Whenever Apache has to generate content, it will ask each of these
content handlers in turn if it wants to have a go at it. mod_jk is
called, so it gets a go at examining the current URL, and decide if it
wants to process that URL or not (for mod_jk, processing a URL means
passing it to Tomcat, and letting Tomcat do the work).
To tell thus mod_jk which URLs we want it to handle, there are the
JkMount and JkUnMount instructions, like :
JkMount /myapp anyname
JkMount /myapp/* anyname
Why two ? because the syntax of the middle part is somewhat
narrow-minded (Rainer would say that it is very precise). If we say
"/myapp" it means "/myapp" and not anything else (like
"/myapp/something"). So to let it know that it should process calls to
"/myapp" /and also/ anything below "/myapp", we need these two lines.
Notice also the "anyname" ? that is the name we gave to our worker, in
the workers.properties file. This is so that, now that mod_jk has
decided to process the current request for "/myapps/something", it would
know to which Tomcat to pass this request.
And JkUnMount ?
That is kind of if, after telling mod_jk to process anything below
"/myapp", you have second thoughts, and decide that after all "certain
things" below there it should not process, but instead it should decline
and tell Apache "no, this is not for me, please handle that yourself".
(See (**) below.)
It could be for instance this kind of thing :
JkUnMount *.gif anyname
thus telling mod_jk : "ok, process all the calls for /myapp, except if
this concerns a gif image. In that case, let Apache do it."
While this was not a direct answer to your question, does it help ?
Note (*) :
If you had two Tomcats, then you'd have something like
worker.list=anyname,anothername
and another section of 3 lines defining where your "anothername" worker
can be found :
worker.anothername.port=8009
worker.anothername.host=anotherhost
worker.anothername.type=ajp13
Note (**) :
That is in fact exactly what it does. Instead of passing the request to
Tomcat, and reading the answer from Tomcat, and passing the answer back
to Apache, it returns a special status code to Apache : DECLINE.
That causes Apache to pass the request to the next propective handler in
the chain. If Apache then does not find any other "special" handler
like mod_jk that wants this request, it will process it itself, using
its own default handler (which just reads and returns the gif file e.g.).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
