The JK 2 Connector

 

 

Overview

The JK 2 Connector element represents a Connector component that communicates with a web connector via the AJP protocol. This is used for cases where you wish to invisibly integrate Tomcat 4 into an existing (or new) Apache installation, and you want Apache to handle the static content contained in the web application, and/or utilize Apache's SSL processing. In many application environments, this will result in better overall performance than running your applications under Tomcat stand-alone using the HTTP/1.1 Connector. However, the only way to know for sure whether it will provide better performance for your application is to try it both ways.

This connector supports load balancing when used in conjunction with the jvmRoute attribute of the Engine.

 

Attributes

All implementations of Connector support the following attributes:

Attribute Description
className Java class name of the implementation to use. This class must implement the org.apache.catalina.Connector interface. You must specify the standard value defined below.
enableLookups Set to true if you want calls to request.getRemoteHost() to perform DNS lookups in order to return the actual host name of the remote client. Set to false to skip the DNS lookup and return the IP address in String form instead (thereby improving performance). By default, DNS lookups are enabled.
redirectPort If this Connector is supporting non-SSL requests, and a request is received for which a matching <security-constraint> requires SSL transport, Catalina will automatically redirect the request to the port number specified here.
scheme Set this attribute to the name of the protocol you wish to have returned by calls to request.getScheme(). For example, you would set this attribute to "https" for an SSL Connector. The default value is "http". See SSL Support for more information.
secure Set this attribute to true if you wish to have calls to request.isSecure() to return true for requests received by this Connector (you would want this on an SSL Connector). The default value is false.

 

Standard Implementation

The standard implementation of JK 2 Connector is org.apache.jk.server.tomcat40.JkConnector. This implementation supports the AJP 2.0 protocol. It supports the following additional attributes (in addition to the common attributes listed above):

Attribute Description
acceptCount The maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 10.
debug The debugging detail level of log messages generated by this component, with higher numbers creating more detailed output. If not specified, this attribute is set to zero (0).
maxProcessors The maximum number of request processing threads to be created by this Connector, which therefore determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to 20.
minProcessors The number of request processing threads that will be created when this Connector is first started. This attribute should be set to a value smaller than that set for maxProcessors. The default value is 5.
port The TCP port number on which this Connector will create a server socket and await incoming connections. Your operating system will allow only one server application to listen to a particular port number on a particular IP address.

 


 

Apache

 

 

Overview

This section explains how to connect Tomcat 4 to the popular open source web server, Apache. It was originally part of Tomcat: A Minimalistic User's Guide by Gal Shachor, but has been split off for organizational reasons. It should be considered a work in progress. Since the Tomcat source tree is constantly changing, the information herein may be out of date. The only definitive reference at this point is the source code.

 

 

Installation

In a nutshell a web server is waiting for client HTTP requests. When these requests arrive the server does whatever is needed to serve the requests by providing the necessary content. Adding a servlet container may somewhat change this behavior. Now the web server needs also to lad the servlet container adapter library and initialize it (prior to serving requests).

When a request arrives, it needs to check and see if a certain request belongs to a servlet, if so it needs to let the adapter take the request and handle it.

The adapter on the other hand needs to know what requests it is going to serve, usually based on some pattern in the request URL, and to where to direct these requests.

Things are even more complex when the user wants to set a configuration that uses virtual hosts, or when they want multiple developers to work on the same web server but on different servlet container JVMs. We will cover these two cases in the advanced sections.

 

 

mod_jk Terminology

The following terms are used in this section:

Worker process A worker is a Tomcat instance that is running to serve servlet requests coming from the web server. In most cases there is only a single worker (the one and only Tomcat process) but sometimes you will run multiple workers to achieve load balancing or site partitioning. Each worker is identified to the web server by the host were it is located, the port where it listens and the communication protocol used to exchange messages.
In-Process Worker This is a special worker. Instead of working with a Tomcat process residing on another process, the web server opens a JVM and executes Tomcat inside the web server process address space. Our discussion in this document is not going to get into this special worker. Note: Tomcat 4 can't be run as this type of worker at the moment.
Web Server Plug-in/Tomcat Redirector For Tomcat to cooperate with any web server it needs an "agent" to reside in the web server and send him servlet requests. This is the web server plug-in, and in our case the web server plug-in is mod_jk. The redirector usually comes in the shape of a DLL or shared object module that you plug into the web server.
Plug-in Configuration We need to configure the web server plug-in so that it knows where the different Tomcat workers are and to which of them it should forward requests. This information, accompanied with some internal parameter, such as the log level, comprises the plug-in configuration.
Web Server Configuration Each web server has some configuration that defines its behavior, e.g. on which port to listen, what files to serve, what web server plug-ins to load, etc. You will need to modify your web server configuration to instruct it to load the Tomcat redirector mod_jk.

 

 

Getting mod_jk

The mod_jk source now resides in the jakarta-tomcat-connectors subproject. Please refer to it for build instructions.

Binaries for mod_jk are available for several platforms in the same area as the Tomcat Binary Release. The binaries are located in subdirectories by platform. For some platforms, such as Windows, this is the typical way of obtaining mod_jk since most Windows systems do not have C compilers. For others, the binary distribution of mod_jk offers simpler installation.

Note: Note: 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.

 

 

Configuring Apache

If you've previously configured Apache to use mod_jserv, remove any ApJServMount directives from your httpd.conf. If you're including tomcat-apache.conf or tomcat.conf, you'll want to remove them as well - they are specific to mod_jserv. The mod_jserv configuration directives are not compatible with mod_jk!

Unlike Tomcat 3, Tomcat 4 doesn't automatically generate the necessary $CATALINA_HOME/conf/mod_jk.conf, and it will have to be created manually. Note that Tomcat and Apache must be restarted after adding a new context.

The basic configuration is as follows:

  1. You will need to instruct Apache to load Tomcat. This can be done with Apache's LoadModule and AddModule configuration directives.

  2. You must inform mod_jk the location of your workers.properties file. Use mod_jk's JkWorkersFile configuration directive.

  3. You should specify a location where mod_jk is going to place its log file and a log level to be used. Use the JkLogFile and JkLogLevel configuration directives. Possible log levels are debug, info, error and emerg. If the JkLogLevel is not specified, no log is generated.

  4. The directive JkLogStampFormat will configure the date/time format found on mod_jk logfile. Using strftime() format string it's set by default to "[%a %b %d %H:%M:%S %Y] "

  5. Use mod_jk's JkMount directive to assign specific URLs to Tomcat. In general the structure of a JkMount directive is: JkMount URL_PREFIX WORKER_NAME. You can use the JkMount directive at the top level or inside <VirtualHost> sections of your httpd.conf file.

 

 

Configuring Tomcat

Tomcat 4 won't automatically generate the Apache configuration file at the moment.

After enabling the AJP 1.3 connector, you need to define workers, using a $CATALINA_HOME/conf/workers.properties file. In most cases, using the example workers.properties given below should work fine, after changing the path values to reflect how your environment is set up.

 

Home