qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: Comparison with RabbitMQ
Date Wed, 11 Aug 2010 14:27:11 GMT
On Wed, Aug 11, 2010 at 9:57 AM, vivek agarwal <koolvivek2006@gmail.com> wrote:
> Hi,
> Thanks for the reply.
> We are planning to use a Java broker as most of our applications are in
> Java. Will this affect performance?

As Gordon mentioned, please try both the Java and C++ broker and see
what fits your needs.
The C++ broker is only available on Linux and Windows.

> Is it possible to use a C++ broker, with Java clients ( I am asking this
> cause I believe a C++ broker will give better performance than Java broker).
Yes it is.
The C++ broker supports the AMQP 0-10 version, therefore it will work
with the python, Java, C++ & C# clients as they all have an 0-10
The Java broker supports AMQP 0-8/0-9/0-10 versions of the protocol.
Therefore you could use any of the clients above and the ruby client
(which only supports 0-8) as well.

If you want at-least-once semantics, then I'd suggest you use the 0-10 version.
>From what I recall the 0-8 version will not give you at-least-once
semantics unless you use transactions.
If your applications are in Java, then you need to use the JMS
interfaces. It will ensure that your application remains unchanged
when you switch to a new AMQP version (or for that matter a different
JMS provider).
The addressing syntax allows you to leverage the AMQP features while
sticking to the JMS interfaces.

If you have further questions, feel free to engage us through the user-list.



> Thanks,
> Vivek
> On Wed, Aug 11, 2010 at 7:19 PM, Rajith Attapattu <rajith77@gmail.com>wrote:
>> On Wed, Aug 11, 2010 at 8:54 AM, vivek agarwal <koolvivek2006@gmail.com>
>> wrote:
>> > Hi,
>> >
>> > We have been using RabbitMQ for quite a bit of time, and recently, we
>> faced
>> > a lot of problems due to increase in volumes of messages. The messages in
>> > RabbitMQ are stored in memory, and hence they are limited by the physical
>> > memory. Is the physical memory a limitation in Apache Qpid also?
>> Physical memory is not a limitation.
>> You could specify a per queue limit to manage memory across your
>> queues and then use flow-to-disk if the limits are reached.
>> The C++ broker supports a per queue limit (in bytes and # of messages)
>> and several policies if the limit is reached.
>> 1. reject (default)  - the producer will receive an exception.
>> 2. flow-to-disk     - the new messages will be stored in disk until
>> the in memory queue has room. - This is obviously going to slow down
>> the performance.
>> 3. ring - start overwriting messages in a ring based on sizing
>> > Again, I also wanted to enquire about the acknowledgment process of a
>> > message. Does the interface supports "At least once" deliver of messages
>> to
>> > consumers, by providing a locking and acknowledgment kind of interface?
>> Yes, both the C++ and Java brokers support that as they both implement
>> AMQP 0-10.
>> > Thanks,
>> > Vivek
>> >
>> --
>> Regards,
>> Rajith Attapattu
>> Red Hat
>> http://rajith.2rlabs.com/
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:      http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org


Rajith Attapattu
Red Hat

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

View raw message