Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of marco.sacchetto81@gmail.com
 designates 209.85.217.173 as permitted sender)
MIME-Version: 1.0
Sender: marco.sacchetto81@gmail.com
In-Reply-To: <1413369351566-4686409.post@n4.nabble.com>
References: <1413356949746-4686401.post@n4.nabble.com>
	<CAFgfHUc2WkrAyYi=Ji4hGL_3vgi0RP9ajR8QOU_yiPEH0t+GQg@mail.gmail.com>
	<1413366578185-4686405.post@n4.nabble.com>
	<CAFgfHUdXvhWrrTRzeRrK2oSHHe4HyvTgL+d0C80-YenerwcjRw@mail.gmail.com>
	<1413369351566-4686409.post@n4.nabble.com>
Date: Wed, 15 Oct 2014 14:44:35 +0200
Message-ID: 
 <CAFgfHUdO7aX9vBGL31L69huBp6X8GyhDTo6LNbm0qiz4LGA7Cw@mail.gmail.com>
Subject: Re: Avoiding shared state between master and slave brokers
From: Marco Sacchetto <marco.sacchetto@pradac.it>
To: users@activemq.apache.org
Content-Type: multipart/alternative; boundary=089e0158bdea897bcc0505757e6a

--089e0158bdea897bcc0505757e6a
Content-Type: text/plain; charset=UTF-8

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 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 <deepakkumarpitti@gmail.com>:

> 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:
> http://activemq.2283324.n4.nabble.com/Avoiding-shared-state-between-master-and-slave-brokers-tp4686401p4686409.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

--089e0158bdea897bcc0505757e6a--