FYI: in 5.9 the broker should handle auto restarting in that scenario. Sent from my iPhone
On Jul 5, 2013, at 11:08 AM, hbakkum <hayden.bak...@gmail.com> wrote: > Right, so I've tried to reproduce the issue again, but now the process does > indeed stop... perhaps I was imagining things :P > > However it still does not restart as I'd like. But if I'm interpreting your > previous comment correctly I could achieve this by creating a custom Locker > which wraps and delegates to the /DataBaseLeaseLocker/ and throws an > /IOException/ if /DataBaseLeaseLocker#keepAlive()/ returns false. And if I > have the following config in activemq.xml then it should then restart the > broker: > > <bean id="ioExceptionHandler" > class="org.apache.activemq.util.DefaultIOExceptionHandler"> > <property name="stopStartConnectors"><value>true</value></property> > </bean> > > Does this seem like a reasonable approach? > > > > gtully wrote >> the idea is that it will stop and restart and on a restart become a slave >> again. >> >> What is keeping the java process up? Can you post a stack trace. >> >> We have the logic in the jdbcIoExceptionHandler to stopConnectors and >> restart when the lock can be required, but this kicks in when >> keepAlive gets an exception, because the db has been restarted for >> example. >> It may make sense to have this sort of failure option on keepAlive as >> an option. So rather than fail with false (shutdown) >> it can fail with an exception so that the IOException handler kicks in. >> >> But for now, the question is what is keeping the java process alive? >> >> >> >> On 4 July 2013 17:51, hbakkum < > >> hayden.bakkum@ > >> > wrote: >>> 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. >> >> >> >> -- >> http://redhat.com >> http://blog.garytully.com > > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Setting-a-Master-broker-in-a-MasterSlave-configuration-tp4668815p4668928.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
