Hi List,
good that you brought up this point.
IMHO many people underestimated this subject in both importance _and_
difficulty.
We know, shared java hosting can be done in 2 ways:
a) one JVM per host
b) many hosts in one JVM
As Remy noted, the java machine does not provide the necessary isolation
for solution (b). Security Managers do their work for security, but not for
stabilty. Solution (a) is expensive.
These fact facts have been standing for many years.
But now, the situation is slightly different!
In my opinion, we can use solution (a), if we utilize clustering.
The PHP folks say, simply make the server stateless and everything is easy.
True, but tomcat does not work that way.
Now, with clustering, we could combine both. Consider the following:
1. Set up a couple of tomcat servers (at least 2). I call them 'node'
These can sit on a single server
2. Cluster and load-balance these nodes. They should been seen as a single
tomcat server .
3. Now use this cluster a in solution (b) above.
4. Each node should be monitored and if a situation arises, that
compromises the node's stability, restart that node.
(Memory nearly exhausted; endless looping threads; ...)
5. Another node should have the complete state of all applications on the
failing node, so no interrupt occurs.
6. precondition: n-1 nodes must be able to operate all vhosts
I see one only one enhancement, that must be done before:
The cluster _and_ the load-balancer must be vhost-aware. With this, you could
achive a RAID-like situation.
It's an array of inexpensive tomcats :-)
just my two cents
R.
Am Donnerstag, 6. April 2006 16:12 schrieb 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):
> - 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Reinhard Moosauer
IT Beratung
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
