12 Oct 2004:

We have just improved your ability to develop web applications using Tomcat as the web application service. We call this new capability the Tomcat Development Service .

We hope that this new service will provide better a more stable and productive learning environment for you. Please let us know of any problems with this new capability.

Rationale and History

In prior quarters, when you wanted to do coursework with a Java web application using JSP and servlets, you installed your web application in a shared tomcat process. What that implied, as we realized after several quarters of tomcat failures at crunch time near the end of a quarter, was that it only took one bad application to affect everyone else's work. Because the Java virtual machine (JVM) was shared by many applications but used one process, an infinite loop or overuse of memory would cause the process, and hence all applications running in it, to fail. In addition, the security of several applications running in the same JVM was always suspect.

We spent a lot of time and effort on addressing this problem. At first, there was a hardware reliability problem to fix on the cssgate/repos server, which we ultimately determined to be due to poor quality or aging CPU fans. In an effort to keep tomcat available, we would try to keep an eye on the shared tomcat service when we could, but it would fail at inopportune times for both staff and students. We created a periodic process that checked frequently to see if tomcat was still running, and to start it if not. We clustered the servers to provide availability if the hardware failed for unforeseen reasons.

None of our efforts addressed the source of the problem, which was not the fact that students make mistakes while learning, but that tomcat either wasn't configured properly or did not have the capability to support a learning environment. We also were not well-versed in setting up and configuring tomcat -- we configured it quickly in Autumn 2002 and didn't delve into it much deeper, as it worked okay when there was moderate usage. During the first year, we felt it could have been a performance problem -- not fast enough hardware -- or a bug in tomcat that caused it to fail under heavy usage.

In the summertime, we upgrade software. Tomcat 4.1.12 was on the list of software to upgrade; some students had downloaded Tomcat 5 on their personal computers and ran into some incompatibilities with the earlier version we had installed. But to keep a consistent environment for the year, we intentionally don't upgrade software unless security patches or fixes are necessary. In addition, we purchased over $300K in equipment to equip and upgrade a mixture of old and new labs, and that equipment needed to be setup and configured to help faculty prepare for teaching and research.

We didn't have a lot of time to investigate and experiment with Tomcat 5 prior to the beginning of Autumn 2004. However, once we did, we found that Tomcat could be configured in a way that better supported a learning -- or what we ultimately called a "development" -- environment. Two features make this possible: name-based virtual hosts and separate JVMs.

Our Solution

Virtual hosts allow one server to look like it is several servers to the people using web applications -- one virtual host per IP address or domain name. In our environment, separate IP addresses per student are not feasible; nor are individual domain names. But separate network ports are, which aren't a solution for a company but work okay for students (what's one more number ;-)?). The support for virtual hosts requires a unique port number anyway to keep the hosts unique and to make it all work. However, all virtual hosts still can share the same JVM by default, which is not a good thing if separate real companies are using the same Tomcat server... and not for students, either.

Separate JVMs require that Tomcat's configuration files, work space and log files be unique -- in a separate directory. If they are unique, then one can start tomcat using a different base configuration than normal. Normally, the environment variables CATALINA_HOME and CATALINA_BASE point to the same directory. CATALINA_HOME always needs to point to where Tomcat was installed on the server; it never changes. CATALINA_BASE defaults to CATALINA_HOME if not set otherwise. CATALINA_BASE points to a base configuration directory; if everything is set up correctly in CATALINA_BASE, and one runs starts tomcat, a separate environment, process and JVM will be created for Tomcat. This is what we call the Tomcat Development Service.

This service runs in the context of the user account in which the startup command was run -- this is your cssgate/repos login account. With some minor changes to the build.xml file to bring in the right Tomcat manager (which allows installation and removal of web applications), one can use the familiar ant commands to compile, build, install and otherwise manage your web applications.