In the case the tomcat zipped installation file has been used, or if during the installation wizard the option for creating a Windows service hasn’t been checked, or finally, if it is required to have multiple Tomcat services running on the server, the Tomcat features to create new services should be used.

Obviously it’s required to have Java installed, in this case, it’s used the JDK.

The following batch script will install a tomcat service named YourTomcat related to a CATALINA_BASE located in c:\YourDir\YourTomcat.

set JAVA_HOME="c:\Program Files\Java\jdk1.6.0_12\"
set TOMCAT_HOME="c:\Program Files\Apache Software Foundation\Tomcat 6.0"
set CATALINA_BASE="c:\YourDir\YourTomcat"
call service.bat install YourTomcat

JAVA_HOME and TOMCAT_HOME are obviously the places where Tomcat and Java are installed.

What’s the CATALINA_BASE? In few words, from the same Tomcat installation (located in this example in c:\Program Files\Apache Software Foundation\Tomcat 6.0, the TOMCAT_HOME) it’s possible to run more than one server instances. Each Tomcat instance has its own deployed web applications, its own logs, its own configuration and so on.

The CATALINA_BASE needs to have those directories structure:

conf/
logs/
temp/
webapps/
work/

In conf/ it’s possible to copy the content of the conf/ directory of the Tomcat installation, and obviously these files have to be customized, depending on what is required for that specific Tomcat service, i.e. the HTTP, AJP and SHUTDOWN ports, and so on.

In logs/ each tomcat will write its custom Catalina logs or the web application specific logs (i.e. handled by Log4J).

In temp/ Tomcat will obviously place temporary files.

In webapps/ the web applications .war will be placed (and exploded).

in work/ the compiled .jsp will be placed.

In few words, an URL like http://www.yoursite.com/home.html is mapped on the file /path/to/your/site/home.html.

An URL like http://www.yoursite.com/javaee/hello.jsp is mapped to the hello.jsp file contained in javaee.war application deployed on all the Tomcat servers defined in the load balanced cluster.

The configuration of the Apache virtual host:

<VirtualHost *>
	ServerAdmin webmaster@localhost
	ServerName www.yoursite.com
	DocumentRoot /path/to/your/site/
	<Directory /path/to/your/site/>
		Options MultiViews
		AllowOverride All
		Order allow,deny
		allow from all
	</Directory>

	ErrorLog /var/log/yoursite-error.log

	LogLevel warn

	CustomLog /var/log/yoursite-access.log combined

    <Proxy balancer://tomcatservers>
	BalancerMember ajp://tomcatserver.yoursite.com:8009 route=tomcatA retry=60
        BalancerMember ajp://tomcatserver.yoursite.com:8010 route=tomcatB retry=60
	BalancerMember ajp://tomcatserver.yoursite.com:8011 route=tomcatC retry=60
    </Proxy>

    <Location /javaee>
	Allow From All
        ProxyPass balancer://tomcatservers/javaee stickysession=JSESSIONID nofailover=off
    </Location>

</VirtualHost>

The most important settings are Proxy and Location.
In Proxy it’s defined a load balancer made with 3 tomcat servers and an URL is assigned to the balancer, in this case balancer://tomcatservers.

The balancer has three members, everyone with its own URL based on the ajp protocol. In this case Apache will connect to the Tomcat servers on their AJP connectors (an alternative would be to use their HTTP connectors).

The Tomcat servers run on the tomcatserver.yoursite.com hostname and each of them opens its own AJP connector on a different port: the first on 8009 (the default one), the second on 8010, the third on 8011 (obviously if they run on the same hostname/IP they must bind to different ports).

Each Tomcat is identified by a route name: tomcatA, tomcatB and tomcatC. The importance of it will be explained later.

In the Location section, a specific path /javaee of the virtual host is mapped on the previously defined balancer balancer://tomcatservers/javaee. So when someone asks for http://www.yoursite.com/javaee/hello.jsp the virtual host will request that JSP to a randomly chosen Tomcat in the balancer members.

What’s the stickysession attribute? It’s a very useful configuration parameter used in conjunction with the route attributes, defined before.

As probably every Java EE (or Web) developer should know, while browsing on a server, it keeps trace of some data about the browsing session in a server-side HttpSession object. For example an ecommerce web application needs to store somewhere the information about the shopping cart of non registered users.

How the server can associate the remote session data with the specific navigation session? This is done through a cookie (or via a GET parameter in the URL) that gives to the server the session ID value.

In Java EE applications, the cookie name to identify the sessions is JSESSIONID.

This is closely related to the management of the load balancing between the Tomcat servers.

If Apache picked randomly one of the Tomcat to handle a single request and if the next request from the same user/browser was forwarded by the balancer to another Tomcat in that battery, things wouldn’t work correctly.

Each Tomcat doesn’t know anything of the existence of other Tomcat in that balancer configuration and especially a single Tomcat server cannot access the information of http sessions handled by another Tomcat.

In few words, when a Tomcat is chosen to handle the first request from a user/browser, it’s absolutely required that, to keep valid session data, the same Tomcat must be used to handle the following requests coming from that browser/user.

If not, on each request, the session data would be lost and simple tasks, such as building a shopping cart would result impossible.

So, it’s required to tell to Apache what is the session cookie name: JSESSIONID and which is the identifier of the routes to each single tomcat Server: tomcatA, tomcatB, tomcatC.

In this way, Apache will append to the end of the cookie value the information about the route to the specific Tomcat.

Java EE Tomcat Load Balancing

Finally, the last thing to set-up Apache, is obviously to add to it the modules required by the previous configuration:

• proxy
• proxy_balancer
• proxy_ajp

About Tomcat configuration, there are just few changes to apply to the default configuration, in the Engine section it’s required to add the jvmRoute attribute.

<Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcatA">

This is related to the route parameter defined in the Apache load balancer. So, tomcatA should be set in the configuration of the first Tomcat server, tomcatB in the second and tomcatC in the third one.

Then, the port where AJP connector listens, has to be set accordingly to the apache configuration, so 8009, 8010, 8011 respectively on the first, second and third Tomcat.

The following is the the configuration of the AJP connector:

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

It’s not directly related to the setup of the load-balancer, but since they run on the same host, each Tomcat should have its own set of ports.

To prevent any conflict you should change the following settings on the second and third servers: Server port="8005" and Connector port="8080".

I hope this tutorial has given a complete overview about every step required to setup Apache and Tomcat to create a simple load-balanced cluster.

Extract both of them where you prefer. I extracted Eclipse in /opt/eclipse and Tomcat in /opt/tomcat6), then run Eclipse.

When you’ll run eclipse it asks you about creating a new workspace (that will be used to store all of your projects), so create a workspace, usually somewhere in your user home directory.

When Eclipse is up and running, choose preferences from the window menu. Choose from the bar on the left: Server, Runtime Environments.

Preferences

Click the button Add, choose Apache Tomcat 6.

New Server Runtime Environment

In the next page, browse on your disk and choose the directory where you previously extracted Tomcat. In my case it’s /opt/tomcat6. Finally click Finish.

New Server Runtime Environment - Server Path

Well, until now we have just told to our workspace where Tomcat “installation” is located on our disk.

But, if we wish to run Java Web Applications within Eclipse, we should setup a Server and eventually assign to it a specific configuration.
Go in the Servers view, right click and choose New, then Server.

Select “Tomcat v6.0 Server” as server type (or probably it will be automatically pre-selected), then, in the Server Runtime environment select box you’ll have to choose “Apache Tomcat v6.0″ (that’s probably the only available option.

New Tomcat Server in Eclipse

Click on Next, Eclipse will prompt you to eventually add (or remove) web projects from this Server, in this case, if your workspace is empty you’ll have not any project to add. So, click Finish.

Add remove Eclipse projects from Tomcat

In the Servers panel, you will see the Tomcat you just added, and in the Project Explorer view, a new Server configuration will magical appear.

So you can edit the configuration file server.xml as you prefer, change AJP or HTTP connector ports and so on, start/stop/debug the server and obviously add and remove projects from it.

Editing Tomcat configuration in Eclipse

It is also possible to add other server “instances”, just right click again in the “Servers” view, and follow the procedure described before.

In this way, you will just a single “Tomcat” binaries location (that you defined in the first step of this tutorial), but you’ll have the chance to add many instances of that server, each of them with its specific configuration (imagine the /conf directory of Tomcat) and its specific web application (imagine the /webapps directory).

Multiple Tomcat Instances in Eclipse

For the more expert ones, it is similar to have more instances on the same tomcat binaries defined on different CATALINA_BASE paths.

I hope this tutorial has been useful, please post any question or comment.