What are you using to figure out that consumers are duplicated? I've seen
misleading information in the clientConnectors section of the JMX displays
(accessed from JConsole) under ActiveMQ 5.8.0 that sometimes looks like
there are more consumers connected than there really are, because it
appears
We're looking to upgrade from 5.9 to 5.10 and are using a network of brokers
topology. In order to keep downtime to a minimum we're looking at upgrading
one server at a time while keeping the other servers active. For example
server A stays active while we shutdown server B and upgrade from 5.9 to
We are using ActiveMQ 5.9.1 over the Azure Cloud. We have a Azure cloud
application that has 4 consumers listening for messages using failover
mechanism . These 4 consumers use message and process these messages
accordingly. The consumers seem to duplicate after a couple of days.
Although it's not
Below is the scenario where we are having the problem...
The client application tries to connect to the activemq broker which is
down, and after n number of retries it does not retry and just waits on a
condition...
#1 0x7f52104162d7 in
decaf::internal::util::concurrent::ConditionImpl::wait(
If anyone interest.
We have splitted the connection pool for producers and consumers. Becuase,
otherwise producers/consumers are sharing, sesstions, transancions,... And
because of the error, we figured, that maybe this is the problem. We also
added, some timeouts and othe settings.
Our configur
The caveauts are here,
http://activemq.apache.org/replicated-leveldb-store.html , at the bottom of
the page.
For the rest, network of brokers and master/slave systems are complementary
solutions, aimed at different problems. Generally, a network of brokers
provides scalability, while master/slave p
Broker redelivery does a resend. So order is lost. Grouping depends on
ordered delivery to terminate so it won't work as expected.
But best to ask the computer with a test of your use cases and expectations.
Client side consumer mediated redelivery will work as expected
On 7 Oct 2014 10:49, "tbenko
Thanks. I agree. I just wanted to be sure that there is nothing like that
available with kahadb before using leveldb based replicated store.
Please let me know if there are any known caveats/limitations/issues with
using leveldb based store instead of kahadb. For e.g. One thing I am aware
of is t
Pure master/slave was removed as not production ready, and since they
already found something production-ready that would work with less effort
(leveldb).
I don't think they will develop the option of having similar functionality
with kahadb as well, what's the purpose of maintaining 2 separate sol
Thanks for these prompt replies. Very helpful!
>> What do you mean? A network storage is already supposed to do that.
>> Nothing
>> provides "real time" anyway, not even ZooKeeper, you always need to wait
>> for a minimum time to detect that your master got faulty, and switch to
>> another serv
2014-10-15 9:09 GMT+02:00 deepakkumarpitti :
>
> 1. I was wondering if ActiveMQ provides some replication support from
> primary to failover brokers in real time so that even if I lose primary
> broker (and its persistent store), my failover broker can continue with
> it's
> own replicated state.
It will depend on the queue depth b/c it is a linear search to find a
match. But all messages will be in memory so it will be quick.
On 15 Oct 2014 06:37, "Kevin Burton" wrote:
> I have the need to check if a given item, with a specific key, is already
> in the queue, or scheduled for future exe
Look at http://activemq.apache.org/clustering.html and
http://activemq.apache.org/masterslave.html for the info you need. In a
nutshell, the master/slave(s) configuration is a structure to provide HA in
an active/passive fashion.
--
Questo messaggio è di carattere riservato ed è indirizzato esclu
Hi,
I am currently running ActiveMQ brokers using the Shared kahadb based
Master/Slave topology. This setup currently uses NFS/Filer for kahadb state
and the primary and failover brokers contend for lock on shared state such
that only one broker is active at a time. However, I now want to avoid us
14 matches
Mail list logo
