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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
