"Henri Gomez" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] 2006/4/6, Remy Maucherat <[EMAIL PROTECTED]>: >> Hi, >> >> This thread started (for whatever reason) on the private list as part of >> an unrelated discussion. The point is to see what could be improved to >> make Tomcat more suitable for shared hosting, which is a very nice goal, >> but unfortunately with very serious issues. >> >> I don't see many improvements possibilities, as I consider the following >> solutions and problems (where each user would at least need its own >> vhost): > >I see vhost as a client virtual server, where the 'client' is not a >real / human end user but someone who ask you to host its applications >with one or many webapps in it. > >> - Every virtual host gets its own appBase folder. Having its own folder >> for JARs just won't work (or it means you were able to use the "shared" >> folder successfully, which I doubt). > >What do you mean ? Did we have actually such own folder of vhosts jars >with its own classloader ? If not could it be done easily ? >
In theory, it should be possible to inject a parentClassLoader into the StandardHost to do this. I don't believe that StandardHost exposes this to JMX, so at the moment, you'd need to use introspection. And, I've never actually tried to do this myself ;-). Of course, the patch to enable doing it with JMX is trivial. >Actually a client application get its classes from : > >- jars in common [lib, endorsed, i18n] and webapps lib directory > >- classes from common [ classes ] and webapps classes directory. > >Could we have instead a by vhost supplemental directory to get its own jar >? > >example : > >vhosta will grab in jars in /home/vhostsa/lib and common [lib, >endorsed, i18n] and webapps lib directory > >vhostb will grab in jars in /home/vhostsb/lib and common [lib, >endorsed, i18n] and webapps lib directory. > >In such case did the classloader for vhosta should be different from >the one for vhostb. > > >>If you use the >> TOMCAT_HOME/TOMCAT_BASE stuff, each user can get its own "shared" folder. > >> - There are still tons of JVMs to manage and monitor, which may be a >> problem. > >Why did there should be tons of JVM ? Couldn't we use a single JVM for >each vhosts ? As many I prefer give more power and resource to a >single JVM that spread thread and memory to many JVM where some could >be at some time very less used than others. > >> - If the connector should be shared, with the servlet containers running >> in separate processes, I don't see how to cross the process barrier >> except by going back to square one (httpd in front, with AJP and many >> JVMs/Tomcats, each with its own vhost). > >That's the current situation now, one Apache 2.x with multiples >virtuals servers, each virtual server with its own JK/AJP worker to >reach a specific Tomcat. > >> Some general problems for production are: > >> - No self tuning of the JVM. > >Of course but it's not better to have may JVM present in system with >memory and thread/system resources use when for exemple users are only >using one of the multiples JVM. > >Imagine for example users for differents country, said asia, europe and >USA. > >You setup one JVM / Application for ASIA users, one for Europeans >users and the third for US users. > >During the day, you'll see activity on Asian JVM, then European JVM >and then on US JVM, but even when only one is really used, the 2 >others are still in machine and consume memory and resources. Sad, >this power could be better used for the really active JVM. > >> - No actual isolation, throttling capabilities, etc, provided by the JVM. > >JVM or OS ? > >> - Impossibility to control memory leaks (impossible to force discarding >> classloaders and all associated class defs and instances, for example). > >What do you means ? > >> - Hard to do thread management (by that I mean, monitor and recover for >> threads stuck in loops or deadlocked). > >Well it's also hard today with a 'dedicated' JVM, the only solution >may be to restart the JVM ... > >> Any ideas ? > >Well if it could be done, I'm sure you're probably the best to imagine >such solution. > > >> I suppose native code could be used to improve the situation in some >> areas (although I don't know how to do it ;) ). > >Native code ? Do you imagine some sort of sub-JVM launching ? > >> Rémy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
