There isn't any eviction strategy or preferred master election strategy for the current lock implementations. They effectively compete around some shared mutex and first one to win is elected master. The lock implementations are pluggable, however, so you can take a look at org.apache.activemq.broker.Locker
Take a look here https://access.redhat.com/site/documentation/en-US/Fuse_MQ_Enterprise/7.1/html/Configuring_Broker_Persistence/files/MQPersistStoreCustomLock.html On Tue, Jul 2, 2013 at 6:36 PM, hbakkum <hayden.bak...@gmail.com> wrote: > Hi, > > I have set up ActiveMQ in a JDBC MasterSlave configuration. I have a use > case where it would be useful to mark a broker as the "Master" broker which > would always take a lock if it was owned by a slave. Is there anyway of > doing this or something similar, e.g. some sort of order of precedence when > brokers compete for the lock? > > I would be able to achieve this perhaps by restarting the slaves when the > "Master" is available but does not hold the lock, however it would be much > cleaner if I could just configure a master broker which always takes the > lock. > > Any help would be most appreciated. > > Thanks, > Hayden. > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Setting-a-Master-broker-in-a-MasterSlave-configuration-tp4668815.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- *Christian Posta* http://www.christianposta.com/blog twitter: @christianposta
