I moved to Artemis 2.9.0 so probably it would be better to open a new thread.
Thanks,
Lorenzo
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Hi,
some changes.
The first issue that I figured out on my broker.xml files was the leading
"/" on all file locations. This was preventing the slave to share the same
storage as the master.
Then I moved to 2.9.0. But I'm still experiencing weird behaviour.
The client application connects rand
It may work as expected, but to my knowledge it's never been tested so it
may not. The NullPointerException you're seeing the master's log file is
more concerning than anything. I'm not sure why that would happen.
Can you reproduce this on 2.9.0 [1]? I'm in the process of releasing 2.9.0
now. The
Hi Justin,
I added all missing parts.
Regarding FS lock, if logs are trustworthy, I can see on the master node:
2019-06-05 08:35:47,492 INFO [org.apache.activemq.artemis.core.server]
AMQ221035: Live Server Obtained live lock
So I'm assuming the lock is working.
On slave I can see:
2019-06-05
Apologies! Preview was working but... don't know what happened.
Java client application exception:
Caught exception! javax.jms.JMSException: AMQ219014: Timed out after waiting
30,000 ms for response when sending packet 71
javax.jms.JMSException: AMQ219014: Timed out after waiting 30,000 ms for
It looks like everything you pasted didn't make it through so there's no
configuration, logging, or client details. Therefore, it's hard to offer
much help.
You say that the "shared storage is provided by vagrant." I'm not familiar
with vagrant. Does it support file or file-region locking so that
Hi all,
I'm trying to setup a simple master/slave cluster with shared store.
I have VMs with RHEL 7.6 running in virtual box VMs with vagrant, Artemis
2.7.0.
The shared storage is provided by vagrant. Host OS is Win 10.
>From logs, it seems that the master is acquiring the lock on the file
sys