James, To the point you made about whether LevelDB is production-ready, I think the consensus from recent threads on this mailing list is that LevelDB in 5.10 (and also 5.11 snapshots, I think) still has more problems than most of the people who've used it are comfortable with. Those bugs will get flushed out sooner if you're able to try out LevelDB and help track them down, but it's probably best to do that in a non-production environment if you can't afford to hit the occasional problem in production.
Disclaimer: I haven't ever run with LevelDB, so these opinions are based solely on the variety of requests for support by people on this list. Search the list archives to see what you might hit, and as always with relatively new features, look carefully at the AMQ JIRA to see what's been reported and what's been fixed. Tim On Tue, Jan 6, 2015 at 9:32 AM, <seij...@gmail.com> wrote: > JDBC Isn’t replicated, it picks the first master as the one that locks the > DB > > , but offers you another way of scaling (albeit slower) the security > > of message persistence to say a commercial RDBMS or open source cluster. > > It is also allows you to do master slave without a “san” - something many > companies > > still do :) > > > > > Is it as fast as Kaha or Level, no not even remotely close. > > On Tue, Jan 6, 2015 at 2:27 AM, James Green <james.mk.gr...@gmail.com> > wrote: > > > Looking at http://activemq.apache.org/persistence.html and wondering > about > > building a cluster of brokers for high availability. > > Seems JDBC was implemented quite some time ago and has been eclipsed by > > KahaDB and now LevelDB but these are local only. There's something very > > shiny and new about LevelDB replication but I'm interpreting this as > > potentially too new for a production environment. > > So is the advice for those needing replicated stores still to use JDBC? > > Just point a number of brokers at the same connection or what? > > James >
