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 ? 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]
