-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gili,
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. True. > * 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk331aUACgkQ9CaO5/Lv0PBdywCfZZISEH2dd7d5MvaP1vdT1EBJ K3kAoLyerD+DbJl0D7L3ucbuc+kZzFPL =UhCi -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
