On Wed, Aug 11, 2010 at 9:57 AM, vivek agarwal <[email protected]> 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 implementation. 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. Regards, Rajith > Thanks, > Vivek > > On Wed, Aug 11, 2010 at 7:19 PM, Rajith Attapattu <[email protected]>wrote: > >> On Wed, Aug 11, 2010 at 8:54 AM, vivek agarwal <[email protected]> >> 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:[email protected] >> >> > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
