activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Setting a Master broker in a MasterSlave configuration
Date Fri, 05 Jul 2013 21:04:07 GMT
I had another look and it won't be that simple b/c the
ioExceptionHandler does not restart the persistence adapter, it just
waits for a checkpoint to complete.
There is a JDBCIOExceptionHandler that validates the lock but if it is
not valid it simply exits the broker.

The idea behind the IOExceptionHandler is to be able to survive
transient errors, like no disk space for kahadb or jdbc connection
loss for jdbc. Losing
the lock really invalidates a persistence adapter b/c the assumption
is that the shared store is no longer consistent w/o a
restart/recovery cycle. Some one
else could be in there!

When the lock is permanently lost the only way to go into slave mode
is to restart the broker to essentially restart the PA and the locker.

To have a restart, you really need an external lifecycle monitor. The
karaf osgi integration will auto restart for you through the pid
Or you could use the java service wrapper or some other process monitor tool.

Or look at the pid factory as a way of building your own java main
line that will restart in this case.

On 5 July 2013 16:09, hbakkum <> 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 LeaseDatabaseLocker and throws an
> IOException if LeaseDatabaseLocker#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?
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at


View raw message