activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: KahaDB Protocol Buffers and the future of ActiveMQ
Date Thu, 02 Oct 2008 17:15:39 GMT
On Thu, Oct 2, 2008 at 1:01 PM, Bruce Snyder <> wrote:
> On Thu, Oct 2, 2008 at 8:18 AM, Hiram Chirino <> wrote:
>> Hi Guys,
>> I've lately been working a new persistence store in the sandbox.  You
>> guys can check it out at:
>> It's similar to the default AMQ store that is used by default today in
>> ActiveMQ 5.x, except that it fixes several short commings that we have
>> noticed in in the AMQ store.  This new store uses a transaction log,
>> but indexes the messages using BTrees which stay consistent on
>> restarts which means that store recovery times are very short even
>> when there are many messages stored in the database. This work is
>> approaching a stable point and I think that this should become the
>> default message store for ActiveMQ 6.0.  We need to start beating on
>> this to make sure it's rock solid.
> Are there any docs about how to hook this into, say, an ActiveMQ trunk
> build so we can start testing it now? I'd like to be able to configure
> it via the activemq.xml so I can switch back and forth.
>> While doing this bit of work, I decided to experiment with using
>> Google protocol buffers to encode the transaction log records and it
>> seems to have worked out well.  I think that we should
>> research/evaluate using protocol buffer based default wire format for
>> ActiveMQ.   In addition to being able to code generate marshallers for
>> many languages, I think we may get some substantial performance
>> improvements from using protocol buffers.  So I'm going to create a
>> new branch in the sandbox to experiment with changing out the
>> wireformat.  Hopefully, the performance gains do manifest themselves
>> and we can work on merging those changes back to trunk.
> Will the new store using Protocol Buffers be backwards compatible with
> with previous releases?

Well the new protocol will not be compatible, but I hope we can
support both protocols concurrently.

> Bruce
> --
> perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
> Apache ActiveMQ -
> Apache Camel -
> Apache ServiceMix -
> Blog:



Open Source SOA

View raw message