tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renato <>
Subject Re: Challenges for Java hosting
Date Thu, 06 Apr 2006 19:10:55 GMT
I have one suggestion regarding tomcat and security
manager, but I don´t know if it fits here. We have a
huge problem managing security configuration (i.e.
catalina.policy). We have a common base policy and an
entry for each virtual host. Sometimes clients put
unmanaged libraries that require special permissions.
We have to reinitialize the JVM to make these
permissions take effect.


--- Remy Maucherat <> wrote:

> 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):
> - 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). 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.
> - 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).
> Some general problems for production are:
> - No self tuning of the JVM.
> - No actual isolation, throttling capabilities, etc,
> provided by the JVM.
> - Impossibility to control memory leaks (impossible
> to force discarding 
> classloaders and all associated class defs and
> instances, for example).
> - Hard to do thread management (by that I mean,
> monitor and recover for 
> threads stuck in loops or deadlocked).
> Any ideas ?
> I suppose native code could be used to improve the
> situation in some 
> areas (although I don't know how to do it ;) ).
> Rémy
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

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

View raw message