It sounds to me like everything is working as expected. To be clear, there isn't a single, canonical view of the cluster overall. Each node maintains its own view of the cluster topology. If one node loses its connection to another node then it's topology information will be updated accordingly and it will attempt to reconnect to the missing node based on its cluster-connection configuration. In your case, it's imprecise to talk about a node not being part of the cluster in general since none of the nodes are actually dead and each node is visible from at least one other node in the cluster.
Justin On Fri, Mar 29, 2019 at 12:20 PM artemisn00b <prahlad.mi...@nokia.com> wrote: > 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 >
