> Would it be desirable for Artemis to support this functionality in the future though, i.e. if we raised it as a feature request?
All things being equal I'd say probably so, but I suspect the effort to implement the feature might outweigh the benefits. > The cloud can manage spinning up another node, but the problem is telling/getting the Artemis cluster to make that server the master now. The way I imagine it would work best is without any slave at all. The whole point of the slave is to take over quickly from a live broker that has failed in such a way that all the data from the failed broker is still available to clients. Maybe I'm wrong about clouds, but I believe the cloud itself can provide this functionality by quickly spinning up a new broker when one fails. So, you would have 3 live brokers in a cluster each with a separate storage node. There wouldn't be any slaves at all. When one of those brokers fails the cloud will spin up another to replace it and re-attach to the storage node so that any reconnecting client has access to all the data as before just like it would on a slave. Or is that not how clouds work? Justin On Tue, Oct 2, 2018 at 10:50 PM schalmers < simon.chalm...@manufacturingintelligence.com.au> wrote: > jbertram wrote > > The master/slave/slave triplet architecture complicates fail-back quite a > > bit and it's not something the broker handles gracefully at this point. > > I'd recommend against using it for that reason. > > Would it be desirable for Artemis to support this functionality in the > future though, i.e. if we raised it as a feature request? > > > jbertram wrote > > To Clebert's point...I also don't understand why you wouldn't let the > > cloud > > infrastructure deal with spinning up another live node when one fails. I > > was under the impression that's kind of what clouds are for. > > The cloud can manage spinning up another node, but the problem is > telling/getting the Artemis cluster to make that server the master now. > From > what I've read and been told, there's no way to failback to the master when > there is already a backup for the (new) master. > > That's what I'm looking for help on and were my original questions. > > If the position from Artemis is that there's no desire for Artemis to ever > work that way, even if we ask/raise a feature request, then we just need to > understand that so we can make design decisions in our application stack to > cater for that. > > > > -- > Sent from: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html >
