On 02/03/2012 11:51 AM, Pavel Moravec wrote:
Hello qpid users,
I am somehow confused about difference between capacity and maxprefetch. Both
define maximum number of messages that can be sent without receiving a response
to the first msg, but maxprefetch is applicable to consumer part of the
communication only.
My questions:
1) "maxprefetch" is applicable rather to Java client only while capacity rather
to C++, python and .NET clients.
Correct.
2) How to setup capacity in Java client (to limit producers to qpid)? I tried using
address string "small-queue;{link:{capacity:'5'}}" but without an effect. I
spotted non-JMS method setProducerCapacity from org.apache.qpid.client.messaging.address
package (within class Link) but I am unable to use it via Connection, Session or
MessageProducer objects.
I don't believe you can at present. The closest it comes is that you can
specify a limit to the command 'buffer' which is similiar but not quite
the same thing.
3) Why Programming in Apache Qpid talks about prefetch having impact to
performance, while I can't find a method to setting it in C++ client?
The performance tips state: 'Consider prefetching messages for receivers
(see Section 2.6, “Receiver Capacity (Prefetch)”)' where section 2.6 is
http://qpid.apache.org/books/trunk/Programming-In-Apache-Qpid/html/prefetch.html
which - in my view - gives a reasonable description of how prefetch
relates to receiver capacity. I'd be interested to hear if that is or is
not clear.
Receiver capacity and prefetch are essentially the same thing. The
receivers capacity determines how many messages it is prepared to buffer
pending fetch() calls.
4) The same doc says prefetch is by default 1,
Where is that? The default receiver capacity for python , c++ and .NET
is actually 0 (i.e. no prefetch is enabled).
while https://cwiki.apache.org/qpid/use-priority-queues.html states it has
default value 5000 - what is correct then?
5) Are there some reasons to have those two features separated? And with
different default values (capacity has 50)?
I don't think there are two features here, merely a difference in how
the JMS client works and how the messaging API implementations work.
Clearly we want to move towards more commonality but JMS is still quite
a different beast.
Hope this helps...
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
