As Jules requested I am looking at the AC api. I report my observations below:
ClusterEvent appears to represent membership-related events. These you can generate from evs4j, as follows: write an adapter that implements evs4j.Listener. In the onConfiguration(..) method you get notified of new configurations (new groups). You can generate ClusterEvent.ADD_NODE etc. by doing a diff of the old configuration and the new one. Evs4j does not support arbitrary algorithms for electing coordinators. In fact, in totem there is no coordinator. If a specific election is important for you, you can design one using totem's messages. If not, in evs4j node names are integers, so the coordinator can be the lowest integer. This is checked by evs4j.Configuration.getCoordinator(). I don't know the difference between REMOVE_NODE and FAILED_NODE. In totem there is no difference between the two. The only other class I think I need to comment on is Cluster. It resembles a jms session, even being coupled to actual jms interfaces. You can definitely implement producers and consumers and put them on top of evs4j. The method send(Destination, Message) would have to encode Message on top of fixed-length evs4j messages. No problem here. Personally, I would not have mixed half the jms api with an original api. I don't think it sends a good message as far as risk management goes. I think people are prepared to deal with a product that says 'we assume jms' or 'we are completely home-grown because we are so much better', but not a mix of the two. Anyway that's not for me to say. Whatever works. In conclusion, yes, I think you could build an implementation of AC on top of evs4j. BTW, how does AC defend against the problem of a split-brain cluster? Shared scsi disk? Majority voting? Curious. Guglielmo
