tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cowwoc <>
Subject Re: One process per webapp
Date Tue, 14 Jun 2011 19:54:17 GMT

>>   1. Always bounce Tomcat directly instead of re-loading the webapp

This is too slow (10-15 seconds) in its current form. If you use the
mechanism I'm proposing restart time is instant (you have a blank Tomcat
instance waiting to pick up a new webapp).

>>   2. Fix the webapp so it doesn't bomb on startup when the library
>>      is already loaded

As far as I know what you are proposing is impossible. Here is what I've

* A webapp must invoke System.loadLibrary() to use JNI.
* If a library is loaded by one ClassLoader and another ClassLoader invokes
System.loadLibrary() the JVM will throw: java.lang.UnsatisfiedLinkError:
Native Library x already loaded in another classloader.
* Tomcat loads each webapp into its own ClassLoader.
* When reloading a webapp, there is no guarantee that the old ClassLoader
will get garbage-collected (thereby ensuring that the old library is
unloaded) before the new webapp is launched. When I reload such webapps, I
get UnsatisfiedLinkError virtually 100% of the time.
* There is nothing a webapp can do to prevent this problem. Either each
webapp needs to run in its own JVM or Tomcat needs to guarantee that the old
ClassLoader is GCed before loading the new webapp instance.

>> Tomcat provides the manager webapp and ant tasks to access it, plus a
>> toolbox of scripts to start/stop/etc. Tomcat. Your needs seem to be
>> fairly specific... why not just roll your own solution?

Because then every user would have to roll their own solution. Right now it
is impossible to reload webapps that use JNI and it is extremely slow to
reload the entire JVM. Fixing this in the official release would benefit
anyone wishing to use JNI (or libraries that use JNI) from within Tomcat.
Nowadays with the rise of RESTful interfaces, it makes a lot more sense to
wrap a RESTful interface around libraries that interface with native code.

Christopher Schultz-2 wrote:
> It sounds like the OP could just wrap the Tomcat launcher in a script
> that looks roughly like this:
> #/bin/sh
> while [ 1 ]
> do
>   ${CATALINA_HOME}/bin/ run >> "$CATALINA_OUT" 2>&1
> done
> This would start a Tomcat and wait for it to finish, then restart when
> the original JVM came down. I suspect using JMX or whatever, one can
> request a Tomcat shutdown which will ultimately terminate the JVM
> (unless some foolish person launched a non-daemon thread at some point).
> The script will re-start Tomcat.
> This just doesn't seem like a difficult thing to implement oneself, nor
> does it seem like something that is widely applicable.

Chris, I'm asking for a lot more sophistication than simply restarting the
JVM. I'm talking about sticking a proxy (on port 80) that acts a front-man.
Then each webapp run in its own JVM in some custom port. The proxy redirects
traffic to the custom ports. Reloading webapps would do the following:

* Grab a blank (loaded without any webapps) Tomcat instance from some pool,
ask it to load the new webapp instance.
* The new instance runs in a different port than the existing instance
* We ask the proxy to forward traffic to the new port instead of the old one
* We ask the old instance to shut down
* Note that traffic moves across instances instantly (without waiting for
the old instance to shut down)

I wouldn't want to try implementing this in terms of simple script files.
It's a lot more involved.

View this message in context:
Sent from the Tomcat - User mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message