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