erceived problem
was that the code couldn't handle a volume that size, not that it couldn't
handle an EFS volume.
On Sep 2, 2016 5:17 AM, "Korny Sietsma" <ko...@sietsma.com> wrote:
> Interesting - we set up ActiveMQ 5.9 successfully on EFS, I'm guessing
> these error messages r
Interesting - we set up ActiveMQ 5.9 successfully on EFS, I'm guessing
these error messages relate to checks made in later versions of the product.
Note that we gave up on this approach - we found that shared filesystem
master/slave had several problems for us when we tested it with network lag
Hi - I'm doing some Artemis testing. I have a Jepsen process that spawns
10 threads, each of which connects to the same queue using the name
"dynamicQueues/testQueue"
And I get an exception on one of the threads:
javax.naming.NamingException: Something already bound at testQueue
at
Hi folks - just wondering if anyone else has tested this and found similar
problems.
I've been testing ActiveMQ in a shared storage master/slave configuration,
using an NFSv4 server for the shared storage. I've tried this both with a
standalone nfs server, and using Amazon's EFS server.
My
Hi - on our test systems, when I query a connection for it's BrokerInfo I
get a BrokerURL of "tcp://activemq00:61616" - our actual host has a fully
qualified domain name that is more like "activemq00.us-east1-1a.foo.bar"
The short host name "activemq00" is largely useless, especially as our
slave
I needed to find the master broker similarly, for our resiliency testing -
you can call connection.getBrokerInfo() (you might have to cast the
connection to ActiveMQConnection if you just have a JMS Connection object),
and then that exposes a pile of information like getBrokerURL() and
isMaster().
Hi folks - I'm testing a system using ActiveMQ 5.9.1 with an NFS server for
shared filesystem master/slave
I'm trying to set up and test failover and fail-back. I'm using Jepsen to
fake a network split, where the Master broker can't communicate with the
NFS server - after some headaches I have
