> I've always been slightly wary of the tight/intimate type of cluster that > VS > solutions end up giving. I'm more of a fan of the first part of your > reply: > > If you replicate the messages in memory (to another machine or two) you do >> not have to force to disk upon commit - you can thus take the disk out >> of >> the critical path. Therefore you can get great throughput even with >> short >> transactions and short messages. >> > > > Two server solutions usually seem more robust than 3+ server solutions; > just > my experience of the Real World. Usually people don't invest enough on > the > infrastructure to make N-way solutions fail deterministically (e.g. they > skimp on network connections and multi-pathing).
You don't have to use VS to do in-memory replication. The primary can send messages to the backup and when the transaction commits it can get an ack from the backup. Then the transaction can be forced to disk later. But the reasons I would use the totem protocol in this application are: 1) Using totem it's easy to do active/active, which seems more desirable than primary-backup. Deadlocks are not a problem because all servers see the same messages, and all messages arrive with a globally unique id. 2) There is a complex relationship between the degree of replication and availability, and the optimal availability is probably more than 2 servers. It's interesting what you say about network availability, but VS is based on the concept that nodes can drop off the group at any time, so network availability need not be perfect. 3) Totem provides a really easy programming model, which makes the code more likely to be correct early on, which itself has an impact on availability. > I am interested in how we could add VS to Qpid/Java though. Could you > point > us to a "Dummy's Guide" for this application of VS (obviously using EVS4J > :-) We don't have the brainwidth to be expert in VS in addition to > working > with AMQP and Qpid. You could read the section called "Advanced Replication Techniques", in Ken Birman's book "Building Secure and Reliable Network Applications." It's available for free on the web. It references some other sections so you may have to go back and look at those. Birman uses causal ordering, not total ordering. And of course you can the read the totem article referenced on the evs4j web page. With EVS4J what you need to know is you get an api that allows you to send a message. Each member gets the message, including the sender, and when the message arrives it arrives in the same order at each member. When a fault occurs, you get notified of the membership change. And you get pretty good throughput.
