tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Moosauer <reinh...@mib1.de>
Subject Re: Challenges for Java hosting
Date Fri, 07 Apr 2006 13:31:06 GMT
Am Freitag, 7. April 2006 15:12 schrieb Remy Maucherat:
> 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.
>

Ok. But you can kill the webapp with the amok-thread. So we will not have a 
break every 3 requests. (the thread can be tracked down to the failing 
webapp. Send a mail with the thread-stack-dump)
The ignore-not-serializable-sessions-objects thing would be very nice! 

> 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).

Maybe it is still much better than the one-vhost-per-vm solution.
I think for hosters with thousands of vhosts, this would be quite interesting.

>
> Note: Tim stated the same concept earlier too.
>
> Rémy

What do you think about my suggestion to enhance the cluster?
(vhost<->node would no more be all-to-all, so you can optimize clusters with 
more than 2 nodes, which also reduces replication overhead)

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

Reinhard

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


Mime
View raw message