startup, shutdown with multiple instances on remote server

[Tom Griffith]

Hello. If anybody has a moinute, I have the following stuation...

One server

Three Tomcat instances

remote access for myself via vpn, so I see the hard drive in windows explorer and can access the command line

I tried to run startup.bat, shutdown.bat, restart.bat in order to restart but they all throw can't find file errors.

I suspect they are lacking the java_home and catalina_home environment variables on the server. Even so, I wouldn't know how this would relate to multiple instances.

however, I ~think~ Tomcat starts the instances on server startup, so somehow it manages that or whatever.

Does anybody know the best way in which I could restart after I deploy web apps, lib and/or config stuff? Thank you so much for reading this and for your help.

[K. Tsang]

First to check are the 3 instances using different ports?

Setting the JAVA_HOME and CATALINA_HOME I think is a must for Tomcat unless you use the full path.

What files do the scripts cannot find? It looks from the path you currently at (eg where you run the script).

Try get one instance working first. Then work your way to 2 and 3

[Tim Holloway]

You can run multiple Tomcats on a single machine. They can all use shared code or be completely different sets of code - even different versions.

Tomcat has 3 core environment variables that must be set before launching. JAVA_HOME indicates the JDK that will run Tomcat. CATALINA_HOME is the shared Tomcat resource directory (bin, lib). CATALINA_BASE is the directory with per-instance files (conf, webapps, temp, work, and log directories).

For the basic single-instance Tomcat, CATALINA_HOME and CATALINA_BASE refer to the same directory, and if you don't explicitly set CATALINA_BASE, it will assume the value of CATALINA_HOME.

Within the CATALINA_BASE/conf/server.xml file, you define that particular Tomcat instance's tcp/ip ports, which should number about 5, including 8080 (http), 8005 (tomcat control), 8009 (proxy pipeline), 8443 (https). I missed one, I think. And I'm not sure about 8005. Close enough.

It's a fundamental limitation of TCP/IP, however, that one and only one application can listen on a given port. So if you have multiple Tomcats, each tomcat (CATALINA_BASE/conf/server.xml) must define a different set of ports. For example, 8180, 8105, 8109, 8143, 8280, 8205, 8209, 8243, etc. The exact numbers aren't critical except that they must be unique and over 4096 (unless running as admin, which I don't recommend).

[Tom Griffith]

hi guys. Thank you so much for replying. I think I am kind of close but I was trying to do this without starting the server. I think they have all three Tomcat Instances as a Windows Service, and that's how they start up. I don't know much about that, so I suspect that JAVA_HOME and CATALINA_HOME are not listed as environment or system variables.

This is Tomcat 5 (I want to upgrade this and the jre (1.4) but hopefully be able to just get this going first).

What I am trying to do is run a parallel web app (app_or.war) which uses jdbc to integrate with Oracle. there is one in place (app_ms.war) which is integrating with SQL Server and has been running for years

1. I copied app_or.war to webapps and it seems to deploy the web app, creates the directories, etc.

2. I copied app_or.xml to conf/Catalina/localhost. The contents of app_or.xml includes the Oracle resource, including this under ResourceParams...

<parameter>
<name>driverClassName<.name>
<value>oracle.jdbc.OracleDriver</value>
</parameter>

However, I am getting SQLNestedException: Cannot load JDBC driver class 'oracle.jdbc.OracleDriver'

....full stack trace in log is cause: java.lang.ClassNotFoundException: oracle.jdbc.OracleDriver


I have tried all alternatives since I read that storing jars in your web app and Tomcat's lib could be an issue. I'v received the same error deploying in these ways...

1. ojdbc14.jar located in %TOMCAT_INSTANCE%/common/lib ~AND~ deployed in the web app (WEB-INF/lib)

2. ojdbc14.jar located in %TOMCAT_INSTANCE%/common/lib BUT NOT deployed with the web app

3. ojdbc14.jar NOT in %TOMCAT_INSTANCE%/common/lib ANd DEPLOYED ONLY with the web app (WEB-INF/lib)

I'm getting the same ClassnotFoundException deploying all three ways. Would you guys know what I'm missing. I would think deploying ojdbc14.jar with the web app would preclude the need to restart Tomcat.

I configured Tomcat 6 (slight differences in the context fle format) on my local and was able to run the servlet, but I had the ability to shutdown, restart, etc. and I had ojdbc14.jar stored in both places (in Tomcat and the web app...as it was in attempt 1 above).

I was also deploying through Tomcat Application Manager thinking there might be a difference doing it that way but it doesn't appear so. Thank you so much again.

[Tim Holloway]

JDBC drivers should not be part of the WAR in well-written applications. In fact, a webapp worth the extra time and trouble that J2EE imposes on you should almost always use a JDBC connection pool instead of having the app grab the driver directly. But that's another matter.

In Tomcat 5, I believe the JDBC jars went in CATALINA_HOME/common/lib. In Tomcat 6 and later, the different libs went away, so it's simpler. Just put it in CATALINA_HOME/lib.

Check what driver classes are actually available. The command "jar -tvf ojdbc14.jar" lists the contents of the jar, and any class whose name ends with "Driver" is a candidate.

[Tom Griffith]

Hi. Yeah, this is a servlet in which I have no access to the source code itself, I have to point it from legacy db to new Oracle db. I have to change the SQL in a config file in which it uses.

I used the same driver when I performed this same operation (repointing the servlet to Oracle) on my local Tomcat using the same driver class (oracle.jdbc.OracleDriver) so I don't ~think~ it's the name, albeit that was with Java 6 (local) and the server is on 1.4. I also tried legacy oracle.jdbc.driver.OracleDriver and it's the same thing, can't find it or whatever.

It seems it can't find it in commons/lib or web_app/web-inf/lib.

Aren't external JARs registered or whatever the moment they are dumped into commons/lib (or deployed with the web app) and don't require a restart.

I only have vpn access to the server (not a virtual desktop or whatever), the server admin is out so I can't really get to any Windows based stuff like Control Panel and sysedit. I have the local drive for the server mapped in windows explorer and can access the drive on the command line. I'm pretty sure Tomcat is registered as a windows service, so it starts up on server restart, so there should be a link to the local jre (but I don't think there's a java-home as a system environment variable due to my initial troubles with the Tomcat startup.bat and shutdown.bat).

Does ojdbc14.jar maybe have to be dumped in all three Tomcat instances commons/lib although I'm only using one? I wouldn't think so.

[Tim Holloway]

You only need one copy of the driver jar. More than one would expose you to potential classpath problems.

For really old stuff, you might need the Oracle thin driver.

As far as registering jars, no, I'm pretty sure that Tomcat scans the jars in the lib directory at startup time and adds each jar to its classpath. So dropping one one a live server would probably not "take".

As far as registering drivers go, older JDBC required that the application code invoke class.forName() on the driver to get it to load, but more modern systems scan meta-information in the driver Jar.

The tricky part can be matching up the jdbc URL to the driver that handles that URL.

[Tom Griffith]

ok. thank you. in the least, the servlet is reading the class (oracle.jdbc.OracleDriver) from the config file although it can't find it, so that's some progress. I still wonder why, although I would change it after testing, ojdbc14.jar can't be deployed ~only~ with the web app (web-inf/lib) and not dumped in commons/lib and be accessible. I would think the Tomcat container would just go to the web app if it couldn't find it registered from commons/lib.

I found this from Tomcat documentation..

Therefore, from the perspective of a web application, class or resource loading looks in the following repositories, in this order:
•Bootstrap classes of your JVM
•System class loader classes (described above)
•/WEB-INF/classes of your web application
•/WEB-INF/lib/*.jar of your web application
•Common class loader classes (described above)

[Tim Holloway]

Try reversing that order. Although different parts of Tomcat have different classpaths. For example, the JDBC ConnectionPool is constructed by Tomcat itself and therefore no WAR's classpath components are part of the classpath of the connection pool or its components.

The one thing you want to avoid is a mix-and-match classpath. If the same class appears in multiple locations, then the actual instance of that class will vary on the context of the class user. This can be especially nasty when you're talking static class properties. So a class should only be defined in one location in the path. Something like log4j.jar can appear in multiple webapps, because as part of the WEB-INF/lib chain, each webapp has its own definition and its own separate classpath. The JDBC drivers, on the other hand, are designed to be shared.

[Tom Griffith]

ok. So jdbc is sort of a special case to that ordering since Tomcat creates a connection pool to all external databases on startup and can't/won't do it at application deployment. Is that right?

[Tim Holloway]

The JDBC drivers are designed to be operating on behalf of multiple processes running concurrently. Any code in TOMCAT_HOME/lib, in fact, has to be able to do that.

Tomcat doesn't simply create connection pools, but if you define connection pools using Tomcat configuration or deployment directives (such as context.xml), then Tomcat will create a pool to match the indicated configuration and will manage it for the benefit of whatever web applications ask for the pool. If the pool is defined in an application deployment descriptor (for a single webapp), it gets created/destroyed when the webapp starts and stops.

Usually a webapp that's doing brute-force connection management won't use a pool, so the driver jar is part of the WAR, but as I mentioned earlier, well-written J2EE apps usually use pooled connections because they're more efficient in a multi-client environment.

[Tom Griffith]

ok, thank you, it seems as though Tomcat by default won't allow brute force connections and forces pooling as deploying ojdbc14.jar with just the war fails to find the driver. Oh, tomcat is running as a windows service and I figured out how to access the service remotely via Computer Manager, restarted the instance, and it registers the ojdbc14.jar driver in the Tomcat lib (and not deploying with the war). thank you again.