Sorry I was late to the discussion. I was sick the whole of last week and this week I had to deal with a few issues and was late in catching up on email.
Both max-prefetch and capacity are only relevant on the consumer side and they mean the same thing. If capacity is specified in the address string it overrides the max-prefetch set for the connection. Currently max-prefetch and capacity works at the session level, not really at the destination level. All though we set message-credits to max-prefetch (or capacity), if we have more than one consumer on the session then completions are sent based on a metric calculated at the session level, rather at a destination level. See QPID-3612 and QPID-3613 There is currently work to ensure we implement capacity properly on a per destination basis for the consumer. There is an outstanding JIRA for producer side capacity and also to align it with the flow control work done on the C++ broker. I believe max-prefetch was retained more for historical reasons. Going forward we should probably just use capacity to avoid confusion. Regards, Rajith On Wed, Feb 15, 2012 at 4:45 PM, Gordon Sim <[email protected]> wrote: > On 02/15/2012 09:23 PM, Pavel Moravec wrote: >> >> 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? > > > Yes, I think that would be a very reasonable request. > > There is a qpid.session.command_limit option that restricts the number of > outstanding commands that can be held. That is similar to the capacity but > (a) is session level rather then producer level and (b) needs to include > other AMQP 0-10 commands, not just message transfers. > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
