Thursday, December 8, 2011

Concurrent Tomcats Different Versions

If you're trying to run concurrent Tomcats in your Windows environment (and presumably, Linux as well, I'll let you know) there are plenty of helpful guides out there that will tell you how quick and easy it is...

The problem is they're making assumptions that may not be true.

1)They assume both of your Tomcats are the same version.
2)They assume both of your Tomcats have the same general structure.

If both of the above conditions are not true, then just setting CATALINA_BASE on the fly and changing a few port numbers is going to crash and fail.

Ask me how I know.

I'm experimenting with new ways to handle SSO with Liferay and my current model calls for a Liferay instance running in a Tomcat bundle along with a separate instance of Tomcat that is NOT running Liferay.

Instance 1: Tomcat 6.0.29 running Liferay 6
Instance 2: Tomcat 6.0.32

Go ahead and try to just set CATALINA_BASE when you start that second instance and see what happens.


The reason should be fairly obvious.

When Tomcat starts up, it looks at your environment variables to find CATALINA_HOME.  Once it has that, it will use it to set up a few other things, like CATALINA_BASE.  Most online guides will  tell you that setting a new CATALINA_BASE as part of the startup script to point to the folders in the second instance of Tomcat will allow both instances to share CATALINA_HOME (because all those jars are expected to be identical) but have separate configurations (Like server.xml, where you'll be setting separate ports between instances.)  The trouble is that as you can see above, these two Tomcats are running slightly different versions.  Also, in a Liferay bundle there are a few other minor differences that will cause trouble is a non-Liferay Tomcat is trying to share resources.

That means you're going to have to completely separate the two.

This isn't hard, but you do have to be careful.

First, create a new environment variable.  I called mine CATALINA_ALT.  That should be set to the Tomcat home folder of your second Tomcat instance.  (Just like how CATALINA_HOME is set to the tomcat folder for the first.)

Next, you'll have to edit the .bat files in the second Tomcat instance to use CATALINA_ALT instead of CATALINA_HOME.  The files I modified to start with are startup.bat, catalina.bat, service.bat and shutdown.bat.

I used a global find/replace to change all occurrences of CATALINA_HOME to CATALINA_ALT.  Then, I did the same thing to change all instances of CATALINA_BASE to CATALINA_BASEALT.  It doesn't matter what you call them as long as they're different from the original and consistent with each other.

Next, go into your server.xml file and change all the ports to something different from the way they're configured in the first Tomcat instance.  (For example, change the connector port 8080 to 8081.)  Again, it's not as important what values you choose as long as they're different and internally consistent.

Now the two Tomcats will operate independently of each other.  (It's okay that hey share the same JAVA_HOME variable, but if you're running some kind of setup where the Java versions also need to be different, then just create an alternate JAVA_HOME variable for the second Tomcat as well.)

This tactic can also be useful if you're running two separate Liferay instances where one of them has been modified through Ext plugins.

Now, ideally you'll want to go through and make sure that ALL of the .bat files are consistently using CATALINA_ALT and CATALINA_BASEALT in your second Tomcat instance's bin folder.  This guide is just to give you a basic understanding of what's going on and what you'll need to do.  These steps should also work for Linux except that you'll work with the .sh files instead of the .bat files.


  1. *I did this in a CentOS Linux environment and it worked. The only difference was that the variables are all created and set inside the .sh files, and I didn't have to set any Environment variables in my .bashrc file.

  2. This comment has been removed by a blog administrator.

  3. This comment has been removed by the author.