just to close the loop on this. I implemented a lease based database
locker that can be tolerant to temporary database outage, like a
failover migration in a cluster or maintenance restart. It may provide
an alternative solution. It is available in a current 5.7-SNAPSHOT
Some more detail in this
Gary Tully uttered:
There should be a single statements element with attributes, so something like:
*ahem*... To much staring and not enough looking, or something. Thanks, that has
done the trick and now all is much better (except for my feeling like a moron).
Many thanks,
Alex.
There should be a single statements element with attributes, so something like:
On 28 May 2012 07:15, Alex Hooper wrote:
> Gary Tully uttered:
>
>> you can set a specific state
Gary Tully uttered:
you can set a specific statement string via the setter on statements element.
eg: peek for lockCreateStatement in the schema
and have a look at
http://fusesource.com/docs/broker/5.4/persistence/JDBC-Customize.html
Hm, yes -- that does look spot on. However, when I try
you can set a specific statement string via the setter on statements element.
eg: peek for lockCreateStatement in the schema
and have a look at
http://fusesource.com/docs/broker/5.4/persistence/JDBC-Customize.html
On 25 May 2012 15:17, Alex Hooper wrote:
> Gary Tully uttered:
>
>> the keepAlive
Gary Tully uttered:
the keepAlive kicks in after the start() has successfully obtained the
lock, so a slave should just block, but a master should check the lock
status every period. By default it does an update using the connection
that has a pending transaction.
Ah, right, the keepAlive is fo
the keepAlive kicks in after the start() has successfully obtained the
lock, so a slave should just block, but a master should check the lock
status every period. By default it does an update using the connection
that has a pending transaction.
It may be that that update has no need to hit the serv
Gary Tully uttered:
[snip]
In your setup, it is odd that the dropped connection does not cause
the lock keepAlive to fail and the broker to terminate. It should,
unless there are tcp level options that need to kick in to see the
half close. Or some connection pool config that can pick up on the
Gary Tully uttered:
You would need to write some code, but the locker implementation can
be easily overridden.
The interface is: org.apache.activemq.store.jdbc.DatabaseLocker
It acquires the lock in start which typically blocks till it can get a
lock and there are periodic calls to keepalive onc
You would need to write some code, but the locker implementation can
be easily overridden.
The interface is: org.apache.activemq.store.jdbc.DatabaseLocker
It acquires the lock in start which typically blocks till it can get a
lock and there are periodic calls to keepalive once the lock is
obtained
10 matches
Mail list logo
