Mapping in workers2.properties 2004-01-11 - By Nikola Milutinovic
Back
> There are actually several ways to map between Apache
> and Tomcat via mod_jk2.
>
> The first is using workers2.properties. If you've
> compiled with -pcre, then perl regular expressions
> should work as well as individual names.
>
> Also, remember that servlets traditionally live in
> /<app-name>/servlet/<servlet-name>. This is
This is the physical location.
> controlled by the web.xml for the particular
> application (context) and is found in:
>
> $TOMCAT_HOME/webapps/<app-name>/WEB-INF/web.xml
>
> The example context is especially confusing, primarily
> due to the name. In Tomcat 4.1.29, you have the
> following:
>
> /examples/jsp/index.html
> /examples/servlets/index.html
>
> However, the actual location of the servlets according
> to web.xml would be:
>
> /examples/servlet/<servlet-name>
This is the deployment path, which can be set to anything you choose.
> So, in your workers2.properties file you will need to
> have the following in order to map all servlets in the
> examples:
>
> [uri:/examples/servlet/*]
> worker=ajp13:unixsocket
Why not "[uri:/examples/*]"?
That way you map an entire "web application" to Tomcat's worker. I'll
elaborate a bit more later.
> or whatever you called your worker name.
>
> While workers2.properties works well for a small
> number of sites, it does not scale very well since the
> match lookup is linear. Another way to manage mod_jk2
> mapping is detailed in the source of mod_jk2.
>
> I know, I know, reading the source is not supposed to
> be a requirement, but then again this is open source
> so you do have the opportunity.
>
> Anyway, in jk/native2/server/apache2/mod_jk2.c, there
> is a little documentation concerning JkUriSet.
>
> Basically, you use Apache constructs to map the
> location and within that you use the JkUriSet
> directive to map the location to the appropriate
> worker.
>
> I've tried both ways, and they both work well.
> According to the source, using JkUriSet is the
> preferred method.
OK, there are three things at work here.
1. Location of your files
You can place files anywhere within your web application's subdir tree.
Servlets go into ./WEB-INF/lib/*.jar (if packaged) or ./WEB-INF/classes/*
(if unpacked). JSP files are anywhere outside ./WEB-INF. All other, static,
files are outside ./WEB-INF.
2. Tomcat's deployment of the web-app
You setup your <Host> and <Context> directives in "server.xml" so that each
web application will have their URI, like
http://your.host.domain.com/context/path/. Your web app will be invoked for
all URIs of this kind. The invocation will come either from a Coyote HTTP
connector or from mod_jk/mod_jk2/mod_webapp.
3. Apache's mapping of URI to a handler
This is the mod_webapp/mod_jk/mod_jk2 stuff. In workers2.properties you map
an URI from Apache to a worker. AFAIK, the URIs of Apache and Tomcat MUST
match or Tomcat will ignore it. So, if you're setting up Virtual Hosts, both
Apache and Tomcat must be the same (as they should, anyway) and deployment
(deployment, not location path!) path of Tomcat's context must match.
With this, there is no real benefit from using either "workers2.properties"
"[uri:...]" or JkUriSet in "httpd.conf", that I can see. Maybe I'm wrong?
> As for in-process, there has been some discussion on
> this mailing list about why in-process does not work
> with the current MPM (multi-processor modules)
> available for Apache httpd. The real problem seems to
> be that there is currently no MPM that runs all of
> apache within one process in UNIX, using threads
> exclusively to handle separate requests.
>
> Actually, this is not quite true since there is an
> experimental MPM that accomplishes this. However,
> according to the documentation this is slower than the
> current worker model (multi-process, multi-thread) and
> not recommended for production work.
>
> The problem is that when multiple processes get
> started, each process attempts to start its own Tomcat
> (if in-process is being used). This can't be done
> using the same server,xml.
>
> In recent kernels (Redhat 2.4.2x, generic 2.6.0,
> 2.6.1) there has been a new implementation of threads.
> It might be possible to build a new MPM that takes
> advantage of this. As far as I know, this is not
> being done (yet). This sounds like a great
> opportunity to make a contribution :-).
What we need is new functionality in mod_jk2 for this, to support the notion
of "one worker process and multiple proxy workers".
Nix.
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)
|
|
