mod_jk
As we saw in Chapter 11, to integrate Tomcat with a web server we need a redirector module that will forward client requests for JSP pages and servlets from the web server to Tomcat. This is done by matching the URL pattern of the request to a mapping in a configuration file. The JSP pages/servlets then handle the forwarded request, generate an appropriate dynamic response and send it back to the client via the module. To address this requirement, Apache's Jakarta project provides a module called mod_jk.
The following schematic diagram indicates the role of mod_jk in the combination of Tomcat and Apache. Here we see that Apache, with the help of mod_jk, redirects all requests for any JSP/servlet components. There may be one or more running instances of Tomcat that will serve these client requests. The redirector usually comes as a DLL or shared object module (.dll for Windows and .so file for Unix/Linux) that plugs into the web server, so Tomcat is said to be a plug-in for Apache:
If you've previously configured Apache to use mod_jserv, remove any ApJServMount directives from your httpd.conf file. If you're including tomcat-apache.conf or tomcat.conf, you'll want to remove them as well as they are specific to mod_jserv. These steps are necessary because the mod_jserv configuration directives are not compatible with mod_jk.
The Apache JServ Protocol
The Apache JServ Protocol (AJP) is a packet-oriented, TCP/IP-based protocol. It provides a communication channel between the Apache web server process and the running instances of Tomcat. Various versions of this protocol are available, including versions 1.2, 1.3, and 1.4. As AJP 1.3 is the most commonly used and well-tested version, we'll use it for our discussion here. Some of the noticeable features of AJP 1.3) are:
AJP increases performance by making the web server reuse already open TCP-level connections with the Tomcat container, and as such, saves the overhead of opening new socket connections for each request. This is a concept similar to that of a connection pool. In the request-response cycle (completion of a request by getting a response corresponding to it), when a connection gets assigned to a particular request, it will not be reused until that request-response cycle is completed. This makes things simple by avoiding the cost of some more opened connections.
The AJP Connector
Tomcat provides a connector that implements the AJP protocol. Most versions of Tomcat support multiple versions of AJP (for example, Tomcat 3.x supports 1.2 and 1.3 whereas Tomcat 4.1.x supports 1.3 and 1.4) and for each AJP version, a connector Java class is provided in the Tomcat installation. Such a class is called an AJP connector.
It is easy to find out which class is providing support for which version of AJP because the class name itself contains the AJP version. For example, in Tomcat 4.0, we'll find a class called org.apache.ajp.tomcat4.Ajp13Connector, which will support AJP version 1.3. Similarly, for AJP version 1.4, Tomcat provides a class named org.apache.ajp.tomcat4.Ajp14Connector. This AJP connector can be configured in the server.xml file of Tomcat. We'll soon cover how to define the AJP connectors.
The New mod_jk2
We have already seen how Tomcat 4.0 provides an AJP connector for coupling Tomcat with a web server like Apache. In Tomcat 4.1.x, a new type of connector called JK2 has been introduced. The functional objective of this connector is the same as that of the original AJP connector, that is, to support the coupling of Tomcat with a web server like Apache. However, it is modified and improved to support the new architecture of Tomcat 4.1.x. This new type of connector supports AJP versions 1.3 and 1.4. Tomcat 4.1.x provides an implementation of this connector as the Coyote connector.
As we know, mod_jk is the module that provides the bridge between Tomcat and Apache. JK2 is the next generation and the corresponding module for Apache is available as mod_jk2.
Worker Implementations with mod_jk
A worker is a Tomcat instance that is running to serve JSP/servlet requests coming from another web server. In most cases, there is only a single Tomcat process, but sometimes we will need to run multiple workers to implement load balancing or site partitioning (mainly required for sites with heavy traffic). We'll see how to achieve this in the Tomcat Load Balancing with Apache section.
Each worker is identified by a host name/IP and port number combination. Here host means the machine name on which the given Tomcat instance is running and port refers to the port on which that instance is listening for any requests.
Plug-In vs. In-Process
Worker implementation in Tomcat with a web server can be done in two ways:
Using Tomcat as a plug-in
The most common implementation of Tomcat with Apache is using the Tomcat process as a plug-in to the running web server process. In this case, mod_jk is required as a redirector component. We'll need to configure the web server plug-in so that it can look up the different Tomcat workers and forward requests to them.
Using Tomcat as an in-process worker
This is a special type of worker implementation. In this case, the web server opens a JVM in its own process and executes Tomcat. Here Tomcat shares the same address space as that of the server process. This is a special type of deployment that provides an advantage in terms of request processing speed and better use of resources. We are not going to cover in-process workers in this chapter because, although Tomcat 3.x supports them, Tomcat 4.x doesn't and there are no plans to implement them in the future.
Multiple Tomcat Workers
There are a number of situations where we may use a multiple worker setup:
We may want different contexts to be served by different Tomcat workers. This setup will provide a development environment where all the developers share the same web server but own a Tomcat worker of their own.
We may want different virtual hosts served by different Tomcat processes to provide a clear separation between sites belonging to different entities.
We may want to provide load balancing, where we run multiple Tomcat workers each on a machine of its own (or maybe on the same machine) and distribute the requests between them.
Getting mod_jk
For Windows, we need the mod_jk.dll for Apache. The Apache 1.3 version is available from the download directory on the Jakarta Project web site: http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.3/bin/win32/i386/. After downloading it, just copy the mod_jk.dll to the modules subdirectory of Apache. The Apache 2.0 version is available here: http://www.acg-gmbh.de/mod_jk/.
| Important |
The version of mod_jk is not dependent on the version of Tomcat. The Tomcat 3.3 distribution of mod_jk will function correctly with Tomcat 4.x and other 3.x versions of Tomcat, such as Tomcat 3.2.1. This is quite logical when we think about it; it's a redirector module residing in the web server process and providing a standard interface for the Tomcat container.
|
For other platforms, we can get mod_jk.so for Apache 1.3.x from its appropriate download directory: http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.3/bin/linux/i386/. After downloading it, just copy it to the libexec subdirectory of Apache.
The Tomcat connectors are handled by a separate subproject of Jakarta, and as such, so are mod_jk and mod_jk2. To make the availability of the Tomcat connectors streamlined, the Jakarta Project has put up a separate URL that is expected to have both the versions of the module (binary and source). The URL is: http://jakarta.apache.org/builds/jakarta-tomcat-connectors/. However, at the time of writing, this download area is largely empty, with only a few connectors and platforms represented.
For the new version of Apache (2.0) the complete range of binaries/sources is not yet populated at the above location, although there are a couple of resources for mod_jk apart from Apache's site. You can get the mod_jk module by either downloading a binary or you could build one of your own.
Building mod_jk On Windows
Here are some basic steps for building mod_jk.dll on Windows:
Download the source of the latest Apache web server from the Apache site (http://www.apache.org/dist/httpd/) and unpack the distribution into any convenient directory such as C:\Apache
Download the latest connectors source from the Jakarta site (http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.4/src/jakarta-tomcat-connectors-4.0.4-src.zip) and unpack it to a convenient directory such as C:\jakarta-tomcat-connectors-4.0.4-src
Set the environment variables:
Now with Microsoft Visual C++, open the DSP file in C:\jakarta-tomcat-connectors-4.0.4-src\jk\native\apache-2.0\mod_jk.dsp or C:\jakarta-tomcat-connectors-4.0.4-src\jk\native\apache-1.3\mod_jk.dsp depending on your server
Using the build option, build the mod_jk.dll
Copy mod_jk.dll to the modules directory of the binary Apache installation
The mod_jk2 source is also in this distribution; use the C:\jakarta-tomcat-connectors-4.0.4-src\jk\native2\server\apache2\mod_jk2.dsp file.
Building mod_jk on Unix/Linux
Here are some basic steps for building mod_jk.so on Linux:
We can get the needed source for the connectors from the Jakarta site: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.4/src/jakarta-tomcat-connectors-4.0.4-src.tar.gz.
Create a convenient directory for building the connector like /usr/local/src/jakarta-tomcat-connectors. We'll refer to this as $CONNECTOR_HOME.
Change to the directory $CONNECTOR_HOME/jk/native.
Run ./buildconf.sh to create a configure script.
Run ./configure --with-apxs=<APACHE_HOME>/bin/apxs. This command will configure mod_jk.so for the version of Apache that apxs belongs to.
Now run make.
We'll see mod_jk.so in $CONNECTOR_HOME/jk/native/apache-<verison>, where <version> is the version of Apache we configured for.
make install isn't implemented yet, so copy mod_jk.so to the libexec (Apache 1.3) or modules (Apache 2.0) directory.
mod_jk2 has a similar procedure:
Change to the directory $CONNECTOR_HOME/jk/native2
Run ./buildconf.sh to create a configure script
For Apache 1.3 run ./configure --with-apxs=<APACHE_HOME>/bin/apxs and for Apache 2.0 run ./configure --with-apxs2=<APACHE_HOME>/bin/apxs
Now run make
We'll see mod_jk2.so in $CONNECTOR_HOME/jk/build/jk2/apache2
Copy mod_jk2.so into libexec or modules as appropriate for your version of Apache
Both modules also come with Ant build scripts. Go into the jk directory, edit build.properties, and run:
Providing you have libtool, the native code for the connectors should be compiled.
No comments:
Post a Comment