activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juan Nin <jua...@gmail.com>
Subject Re: LeaseDatabaseLocker and parallel masters
Date Thu, 17 Apr 2014 01:02:10 GMT
I'm about to start using the LeaseDatabaseLocker, but just for the
active/passive piece.
For the store itself I'm using a common NFS share with kahadb, since we've
had issues with the NFS filesystem lock.

Would like to also hear comments for the same but when using this approach
for storage instead of databse.

Thanks in advance.

On Wed, Apr 16, 2014 at 3:18 PM, oliverd <oliver.deckert@hotmail.com> wrote:

> when using JDBCPersistenceAdapter with LeaseDatabaseLocker the master node
> needs to extend the lease for the next interval
>
> in case, there is a long running GC (longer than the lease extend time)
> then
> the slave will take over and the old master will detect after the GC
> completes that it has to step back (and stop)
>
> during testing it takes some time until the old master really stops (can be
> up to 20 secs during tests, in case there are many client connections that
> stress the node)
> during that time clients connect to both masters until the old master has
> stopped transports
>
> I have seen clients getting SQL exceptions due to duplicate keys on insert
> to the MSGS table during that time and so I was wondering what is the risk
> of getting potential inconsistencies in client state (messages pretend to
> have failed) or even the the message store
>
> is there any chance that the message store can get inconsistent in such a
> situation?
> as longer GCs cannot be prevented under all circumstances a message store
> inconsistency as a follow up issue would add a certain risk to the
> LeaseDatabaseLocker option
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/LeaseDatabaseLocker-and-parallel-masters-tp4680368.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message