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.
