tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <r...@apache.org>
Subject Re: Challenges for Java hosting
Date Fri, 07 Apr 2006 13:12:01 GMT
Reinhard Moosauer wrote:
> 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 had thought about this solution.

However, there are issues, as clustering is quite expensive (if there is 
more than one node, lol), and is incompatible with many applications. So 
for starters, clustering should be updated to add an option to not yell 
when a non-serializable attribute is added to a session, it should only 
operate with one node and then periodically (not too often, so that 
applications with do-it-yourself state will not break too often) start a 
second node, switch the traffic to it, and stop the first one. A similar 
process could also be done when redeploying things, etc. For regular 
hosting, this should provide good enough reliability (some state loss, 
but very decent availability).

I don't think it's actually doable to host Java webapps which break 
every 3 requests (going into infinite loops or deadlocking, etc), however.

Another downside is that the server needs to have CPU and memory 
headroom, since there will be a lot of full replication of sessions 
(during a node transition).

Note: Tim stated the same concept earlier too.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message