tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Challenges for Java hosting
Date Fri, 07 Apr 2006 07:56:02 GMT

"Henri Gomez" <> wrote in message
2006/4/6, Remy Maucherat <>:
>> 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 
>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:
>> For additional commands, e-mail:

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

View raw message