OK, so you need to figure out architecturally what you're looking for.

An ActiveMQ message exists on only a single broker at a time.  From a given
broker, it can be forwarded to a consumer of the message, which might be an
client or might be another broker that is "consuming" the message in order
to pass it on to its own consumer(s).  This basic understanding is
fundamental to the rest of what I'm going to describe.

There are two ways to group brokers together in ActiveMQ.  One is to have
multiple active brokers connected in a network (Network of Brokers), where
a message is passed from broker to broker till eventually it is delivered
to a client for consumption.  Having multiple brokers allow you to scale
out and handle more consumers than a single broker can handle alone, to
address geographic issues (including managing performance with high-latency
network links due to distance), and to logically partition your clients to
achieve certain goals.  There is still overhead from using the network of
brokers approach, because the broker-to-broker work of forwarding messages
isn't free, so it doesn't make ActiveMQ infinitely scaleable, but it can
help.  The other type of grouping is a master/slave grouping (typically a
pair, but it can be more than two), where all brokers in the grouping are
responsible for the same set of messages and where only one broker in the
grouping is active at a time; the others are simply hot standbys, waiting
to take over in the event that the master dies.  Both types of groupings
can provide some form of redundancy and fault tolerance, though the way
each does it is obviously different and the behavior during an anomaly is
different as well.  It's possible to combine the two types of groupings, by
having a network where the connections from one broker go to whichever
member of a master/slave grouping is the active one at any point.

What you've described in this thread sounds like you're doing master/slave
using Zookeeper and replicated LevelDB, which is why you only have one
active broker at a time.  If you want a network of brokers, then you need
to configure one using the options described in the page you linked.  But
keep in mind that, as I said at the beginning, a message will live on only
a single active broker at a time, which means that in a network of brokers
where a producer is on one broker and the consumer is on another, the
message will go first to broker 1, then be forwarded to broker 2, and
finally be delivered to the consumer, so there's an extra hop it need to
take before it reaches where it's going.

Taking a step back, though, it's not at all clear what you're actually
trying to accomplish.  What failures are you trying to guard against?  What
should happen when they occur, for consumers in each location?  You've
asked for help figuring out a few specific issues you're running into, but
without knowing what you're actually trying to do, it's hard to know if
you're even going in the right direction, and if you're wasting your time
on the problems you're hitting and should be doing something different.

Tim

On Mon, May 2, 2016 at 12:44 AM, sekaijin <jean-yves.terr...@sap.aphp.fr>
wrote:

> Thank you very much. that's what I understood from the master / slave
>
> what I want to do is http://activemq.apache.org/networks-of-brokers.html
>
> But I always have a master / slave behavior
>
> A+JYT
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/broker-network-replicated-levelDB-config-problem-tp4711416p4711421.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Reply via email to