qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Vogel <drewpvo...@gmail.com>
Subject Re: Why use the C++ broker versus the Java broker?
Date Fri, 05 Nov 2010 21:25:39 GMT
Thanks for the explanation. I think I'll stick with the Java broker
for compatibility.

On Thu, Nov 4, 2010 at 8:23 AM, Gordon Sim <gsim@redhat.com> wrote:
> On 11/03/2010 04:09 PM, Drew Vogel wrote:
>> Hi. I'm new to Qpid (and AMQP in general). I'm having a bit of trouble
>> determining which broker to use. The compatibility page[1] says:
>>         There are two brokers:
>>         C++ with support for AMQP 0-10
>>         Java with support for AMQP 0-8, 0-9, and 0-10.
>> The C++ broker supports only a subset of what the Java broker does, so
>> is there any reason (other than the never-ending performance
>> comparisons between Java and native languages) to use the C++ broker?
>> Is the Java broker being replaced by the C++ broker?
> No
>> Is the C++ broker
>> intended mainly for platforms without a reliable Java run-time?
> Not really
>> The
>> permissions structure seems to differ between the two brokers, with
>> the C++ broker relying on a newer ACL system, but I haven't used it
>> yet, so I'm relying on the (somewhat sparse) documentation. I've tried
>> to search the list archives for answers to these questions but the
>> only info I found referred to version 0.6, so I'm not sure that the
>> info is still current.
>> Will someone explain this to me? Is this something that should be in
>> the FAQ or am I just missing something obvious?
> I think its really a question of personal preference at this point in time
> (some people feel more comfortable with one broker, others with another).
> The java broker can run pretty much anywhere there is a jvm, the c++ broker
> is more restricted (at least at present). The c++ broker has support for
> some 'native' features (e.g. RDMA). As you point out the java broker also
> speaks all versions of AMQP to date (the only broker known to do so!).
> Ultimately I would hope the choice would not be too significant and
> switching between the two as needed would not cause much disruption to an
> application, at least at the semantic level. We are moving towards a more
> uniform feature set and a more uniform management schema, but are still some
> way of that.
> Thats just my 2cents...
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

View raw message