On Tue, 2021-11-30 at 17:20:31 +0100, Vilius Šumskas wrote: >[...] > As an alternative, does anybody know if I can use non-HTTP SSL load balancer > and set client URI to something like ssl://loadbalancer_host:61616 ? I'm > thinking, if slave servers do not respond to the request until they become > master maybe that would allow me to have a simpler configuration for my > clients. If I will ever need to add more slaves I would just add them under > the same load balancer.
Yep. That's what JB meant with "but not bound as the broker is waiting for the lock". Using an external hw LB is how we currently use ActiveMQ and it works great. Just make sure that your loadbalancer healthchecks check all the protocols you are using and not just one protocol or just pinging. > If that's possible, which of the methods will be faster? We are deploying a > point-of-sale application and I want the failover to be done in an instant, > without losing any transactions (if that's possible :)). Producers always have to deal with network or mq being down, see <https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing>. ActiveMQ is polling to see if current master is up and you don't want to poll NFS so often. How does you application currently deal with the fallacies of distributed computing when you're doing syncronous integrations? BR, - Simon > -----Original Message----- > From: Jean-Baptiste Onofré <j...@nanthrax.net> > Sent: Tuesday, November 30, 2021 6:01 PM > To: users@activemq.apache.org > Subject: Re: ActiveMQ 5.16.x Master/Slave topology question > > Hi, > > masterslave: transport is deprecated. You can achieve the same with > randomize=false basically. > > Correct: updateClusterClientOnRemove is only for network connection, but when > you have active/active (so a real network). > > No, the clients won't be stuck: they will reconnect to the new master. > > Let me illustrate this: > - you have a NFS shared filesystem on machine C > - machine A mount NFS filesystem (from C) on /opt/kahadb > - machine B mount NFS filesystem (from C) on /opt/kahadb > - you start brokerA on machineA, brokerA is the master (transport connector > tcp on 61616) > - you start brokerB on machineB, brokerB is a slave (transport connector tcp > on 61616, but not bound as the broker is waiting for the lock) > - in your client connection factory, you configure the broker URL with > failover:(tcp://machineA:61616,tcp://machineB:61616) > - as brokerA is master, your clients are connected to brokerA > - you shutdown brokerA, brokerB will take the lock and become the new master > - your clients will automatically reconnect to brokerB > - you start brokerA, it's now a slave (as the lock is on brokerB) > > Regards > JB > > On 30/11/2021 09:45, Vilius Šumskas wrote: > > Thank you for your response! > > > > Just out of curiosity, what is this masterslave:() transport is about then? > > > > Also, if I don't configure network connection will > > updateClusterClientsOnRemove parameter take effect? > > > > My main concern is that clients will go into stuck state during/after the > > failover. I'm not sure if everything I need is just handle this in the code > > with TransportListener or do I need to set updateClusterClientsOnRemove > > and updateClusterClients on the broker side to make failover smooth? > >
