@andreas-gilbert if you do that you effectively have a one node cluster (the other node is just a listener). That means if the one node dies then the cluster stops working altogether, thus you have no fault tolerance. The only other possibility if you need a two-node cluster is using the standalone cluster and using AtomixClient on those two nodes
in that case, your two nodes can crash independently without effecting the cluster since consensus is being done in a separate cluster of e.g. 3 nodes
will catch up on all the other conversations throughout the day
@kuujo re: the problem that @taobaorun hit the other day, it would actually be pretty sweet if we could detect inconsistencies between the a server's configuration and the log it's reading and give a nice warning.
@andreas-gilbert The doc page on fault tolerance (http://atomix.io/atomix/docs/fault-tolerance/) talks a bit about how many failures can be tolerated by different node configurations. The way this works is pretty typical for any strongly consistent system.
I think it’s easy… servers just need to store their server address in their logs and validate that the logs in the log directory are for the same server by address. Currently it’s done by server name, but servers usually have the same name on each node