For what it's worth, the broker is pretty much at the mercy of the
filesystem here. The broker attempts to acquire a file lock using standard
Java file APIs. If the filesystem allows those API calls to complete
normally (i.e. without throwing an exception) then the broker must assume
they were succ
Failover issues were due to inability to take the lock on the filesystem.
Moving to an external NFSv4 solved the problem.
Unfortunately, from logs this is not immediate. Actually, the backup server
says that it acquires the backup lock even if this is not true.
Thanks for help.
--
Sent from:
Also, if you paste either configuration or logs in the future *please* make
sure they are well formatted (e.g. proper indentation, no wrapping). Bad
formatting makes everything much harder to read (and therefore harder for
you to get help).
Justin
On Wed, Jun 12, 2019 at 3:10 PM Justin Bertram
Nothing jumps out at me as problematic in either the configuration or the
logs.
The broker ships with a number of HA examples. What happens if you run the
example at examples/features/ha/non-transaction-failover? You just need to
run the command 'mvn verify' from the example directory. The example
Hi all,
I first tried with Artemis 2.7.0 but I didn't make it, now I'm trying with
Artemis 2.9.0, still looking for some luck.
What I want to achieve is a basic shared storage master/slave cluster with
static discovery.
I have a java client that connects to the master. Java code is provided
be
