activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Sacchetto <>
Subject Re: Avoiding shared state between master and slave brokers
Date Wed, 15 Oct 2014 12:44:35 GMT
The caveauts are here, , 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 provides HA when you're facing
particularly important (and as such, persistent) messages.
The type of replication in master/slave is another issue; for sure going by
leveldb you save yourself from depending on a single point providing the
storage (important when you can't or don't want to rely on the storage
provider, as with cloud computing resources). But on the other hand I
wouldn't define it a "simple" solution; consider that the zookeeper service
will have to be mantained as well, will use computing and network
resources, and will require a minimum of 3 nodes in a HA environment.
All in one, I'd say that there's no perfect fit, you should aim at the
solution which best fits your needs and expectations.

Marco S.

2014-10-15 12:35 GMT+02:00 deepakkumarpitti <>:

> 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 that there is no multi-levelDB like multikahadb or mkahadb
> persistence
> adapter to separate out data for different destinations in different
> directories.
> Also, my requirement is mainly high availability (wherein one broker goes
> down and another is ready to take over with replicated state) and not
> scaling -- this can be achieved with simpler Replicated LevelDB store as
> well as with complex network of brokers topology. My understanding is that
> using replicated leveldb store is more simpler (in terms of maintaining,
> managing, monitoring and debugging issues) and recommended here instead of
> using network of brokers. Please let me know if I am missing something
> here.
> Thanks,
> Deepak
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message