Hi Gordon,
the "default prefetch is 1" is my conclusion from Section 2.6: "By default, a
receiver requests the next message from the server in response to each fetch
call, resulting in messages being sent to the receiver one at a time."
Anyway, that is rather an explanation of prefetch, whereas default values are
later on provided (500 for Java client).
I agree that prefetch and capacity is something else (though having something
common in consumer side).
What I am missing in Java client (and what in fact triggered writing of my
original email) is ability to automatically apply/follow producer flow control
in Java client. Using the plain programming skeleton from Spout.java (or
spout.cpp), we are "just" sending messages with no session synchronization
(like session.sync() ). In C++, when I setup capacity to e.g. 50, then:
- assume the broker applies producer flow control by reaching a queue its 80%
capacity
- so it stops ACKing messages from the producer but further messages are still
put to the queue
- so then C++ send method is blocked by C++ client library after sending 50
further messages
While in Java client without ability to setup capacity, Java client can send to
the queue any further number of messages, simply ignoring it hasn't received
ACKs. Only when the client would try to close the session or connection, it is
blocked (in AUTO ACK mode) until ACKs are received. Applying prefetch has no
impact.
So the only way (I found so far) is adding session.sync() after sending a bunch
of messages. What is not ideal not only from performance point of view.
I know there are more important issues with Java client, but is the request of
adding capacity to Java client reasonable?
Kind regards,
Pavel
----- Original Message -----
> From: "Gordon Sim" <g...@redhat.com>
> To: users@qpid.apache.org
> Sent: Friday, February 10, 2012 8:47:33 PM
> Subject: Re: maxprefecth / capacity concerns
>
> 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:users-subscr...@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org
