activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Is JDBC still used?
Date Tue, 06 Jan 2015 16:53:18 GMT

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.


On Tue, Jan 6, 2015 at 9:32 AM, <> 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 <>
> wrote:
> > Looking at 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

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