The low memory situation in these tests is mainly caused by a high number of
client connections leading to a high number of transport threads (not using
NIO). I noticed that the marshalling cache used with openwire eats up quite
a lot of memory. This cache can be reduced. So, the test is running un
The broker reads its sequence id from the store when it has the lock,
so the duplicate detection will ensure a write failure on the next
send by the old master. The worst that can happen is duplicate
dispatch, messages that were in flight in the master, will be resent
by the slave.
However to miti
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 instea
