tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Configuration help with tomcat connectors
Date Sat, 09 May 2009 21:53:13 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message