Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: error (nike.apache.org: encountered temporary error during SPF
 processing of domain of hayden.bakkum@gmail.com)
Date: Thu, 4 Jul 2013 09:51:12 -0700 (PDT)
From: hbakkum <hayden.bakkum@gmail.com>
To: users@activemq.apache.org
Message-ID: <1372956672708-4668884.post@n4.nabble.com>
In-Reply-To: 
 <CAH+vQmOxM0ieJjdbWK9c4aOW5zTtqJrZHmtf_eqDDAz0N0TjKA@mail.gmail.com>
References: <1372804603620-4668815.post@n4.nabble.com>
 <CAH+vQmOxM0ieJjdbWK9c4aOW5zTtqJrZHmtf_eqDDAz0N0TjKA@mail.gmail.com>
Subject: Re: Setting a Master broker in a MasterSlave configuration
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for this. I've managed to configure the database lease locker such
that the master will reclaim the lock if it is held by a slave. However,
I've encountered another issue while testing failover scenarios, that is, if
a slave yields the lock due to the master starting then the slave broker
shuts down. What's odd here is that while the broker shuts down the java
process is still running. In this situation I would have expected (well, at
least preferred :P) the slave to yield the lock, stop its transport
connectors and then continue its polling task to obtain the lock in the
event of another master failure.

I've taken a look at the /Locker/ interface, in particular the /keepAlive()/
method. The javadoc states that if this method returns false, then the
broker will indeed terminate, so unfortunately, it looks like a custom
/Locker/ implementation won't help me here either.

Is there something I'm missing or any way of changing the broker behaviour
when the lock is lost?

Thanks,
Hayden.


--
View this message in context: http://activemq.2283324.n4.nabble.com/Setting-a-Master-broker-in-a-MasterSlave-configuration-tp4668815p4668884.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.