tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: One process per webapp
Date Tue, 14 Jun 2011 21:41:57 GMT
Hash: SHA1


On 6/14/2011 3:54 PM, cowwoc wrote:
>>>   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).

So, now you want Tomcat to launch multiple copies of itself as hot
standbys for /potential future webapp deployments/? We'll never do this.

>>   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.

Certainly not.

> Here is what I've seen:
> * A webapp must invoke System.loadLibrary() to use JNI.

Must it? You can load a native library at a higher-level instead of in
the webapp itself and avoid all of this.

> * 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.

I don't believe this has anything to do with ClassLoaders.

> * 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.

I don't think the ClassLoader ever unloads the native library. I haven't
found any documentation that suggests that it will.

> * 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.

Or you can put your .jar that wraps your native library in Tomcat's lib
directory and take it out of your webapp. That's not the most portable
solution, but neither is using a native library in the first place.

>>> 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.

Yes, everyone who wants this solution would have to roll their own. From
what I can recall, you are the first one who has requested this
capability, so I suspect we wouldn't be saving thousands of staff hours
by implementing whatever-it-is that you are suggesting -- something like
a Tomcat-based hypervisor for multiple Tomcats.

> 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.

It's not a good excuse, but native libraries are a pain in the ass in
Java. If you use one, be prepared to have your ass hurt.

> 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.

Aah, you are a REST guy. That explains the constant appeals against
practicality. ;)

If you wrapped your JNI library with a REST interface, couldn't you
avoid all this foolishness?

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message