Hm, that does make sense. I'll test it out and see how it works with the requirements.
I still don't understand this - I'm adding iptable rules on Machine1 to drop Machine2. So, Machine1 and Machine2 can't communicate with each other, but both can communicate with Machine3. After I add the iptable rules, (my assumption is) Master1 reports to the cluster that it can't communicate with Master2, and hence, Slave3 comes live (probably because Master2 is removed from the cluster). So, Master1, Master3, Slave3 become the live nodes of the cluster. Master2, and Slave2 are also listening, but they aren't part of the cluster. This behavior is consistent across all cases, based on which machine you add the iptable rules to. So, if I had done the same thing and added iptable rules on Machine2 to block Machine1, then Machine1 would've been removed from the cluster. Is this behavior expected? How does Artemis decide which node to remove from the cluster in these type of cases where M1 and M2 can't communicate b/w each other but both can talk to M3? Note that this is without setting <vote-on-replication-failure> to true. -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
