Hi Pavel,
Sorry I can't be any more help. Given what I said previously based on my casual rummage through the source code my bet is that configuring the producer capacity simply isn't supported on the Java client run time. My comment below about "Hmmm scratch that.. I'm typing this as I'm looking, I've just tried "grep -rH getProducerCapacity ." and the only place where that seems to be referenced is in Link.java, so I'm now suspecting that the above sets the value, but nothing is using it yet" is my best bet on the subject.

Unless a Java client runtime guru can step in and prove us wrong I'd say raise a Jira on it.


I have to admit that I'm not really clear on how the capacity stuff works (on C++ or Java really). I'm fairly sure that the consumer capacity (AKA prefetch) maps to an internal queue in the client runtime (I think in the old qpid::client API there was a local queue explicitly involved in the API, though I'm not overly familiar with that API).

I assume the consumer capacity works by allowing the client runtime to pull messages as fast as it can asynchronously to the client application in order to minimise round trip network delays that may be caused by a more chatty synchronous network mechanism.

I'm not so sure on the producer capacity though.....

Good luck with your digging around.
Cheers
Frase


On 07/02/12 08:26, Pavel Moravec wrote:
Hi Frase,
thanks for your comments and hints. I tried various attempts including capacity 
option in address string and also direct calling of setProducerCapacity but 
without an impact.

I will debug it somehow more to pinpoint what is wrong and raise JIRA later on, 
as currently it seems there is no option to apply capacity limit (i.e. 
setCapacity from C++) in Java client.

Kind regards,
Pavel


----- Original Message -----
From: "Fraser Adams"<fraser.ad...@blueyonder.co.uk>
To: users@qpid.apache.org
Sent: Saturday, February 4, 2012 12:02:04 PM
Subject: Re: maxprefecth / capacity concerns

Hi Pavel,
I *think* that they are the same thing.

With C++ I've only used qpid::messaging and that *definitely* has a
default consumer capacity of 1 and I "think" a default producer
capacity
of 50, so if you write a qpid::messaging consumer by default its
performance won't be great hence it's almost always a good idea to do
a
setCapacity() on the consumer session to something sensible.

In Java I *think* the default is 500, but I've never had reason to
mess
around with it. I only picked up on this stuff when I was ahem
"surprised" that my Java consumer was faster than my C++ consumer....

Re your question 2. according to
http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch03s06.html
there are JVM arguments too e.g.


max_prefetch    int     500     Maximum number of messages to credits.

This could also be set per connection (see connection paramters) or
per
destination (see the |capacity| option under link properties in
addressing).


Though that looks like receiver capacity and it sounds like you're
talking about sender capacity?

Ex. |-Dmax_prefetch=1000| property specifies the message credits to
use.

There's a related Connection URL Property

|amqp://guest:guest@test/test?max_prefetch='1000'
&brokerlist='tcp://localhost:5672'|

Again it's called prefetch so I suspect this relates to the consumer
capacity in C++ qpid::messaging.

also as you've commented there's

|my-queue; {create: always, link:{capacity: 10}}
|
Again this would seem to relate to consumer capacity.

Unfortunately I can't see anything obvious in the documentation that
looks like it maps to producer capacity.


I used your comment on "setProducerCapacity" as a "seed" for a few
greps, this is called from AddressHelper in the same package


              if (((Map) address.getOptions().get(LINK)).get(CAPACITY)
instanceof Map)
              {
                  MapAccessor capacityProps = new MapAccessor(
                          (Map) ((Map) address.getOptions().get(LINK))
                                  .get(CAPACITY));
                  link
                          .setConsumerCapacity(capacityProps
                                  .getInt(CAPACITY_SOURCE) == null ? 0
                                  :
                                  capacityProps.getInt(CAPACITY_SOURCE));
                  link
                          .setProducerCapacity(capacityProps
                                  .getInt(CAPACITY_TARGET) == null ? 0
                                  :
                                  capacityProps.getInt(CAPACITY_TARGET));
              }
              else
              {
                  int cap = linkProps.getInt(CAPACITY) == null ? 0 :
linkProps
                          .getInt(CAPACITY);
                  link.setConsumerCapacity(cap);
                  link.setProducerCapacity(cap);
              }

In the first block above it's talking about "CAPACITY_SOURCE" and
"CAPACITY_TARGET" in the code these are strings "source" and "target"
respectively. The first block also seems to be looking for a Map
value
for the capacity property of link so I wonder......how about trying

|my-queue; {create: always, link:{capacity: {source: 50, target:
|200}}}|

I haven't tried this, and I've just got there by looking at the code,
but it looks plausible. I've not come across any documentation that
covers this either, but it *might* just help.


Hmmm scratch that.. I'm typing this as I'm looking, I've just tried
"grep -rH getProducerCapacity ." and the only place where that seems
to
be referenced is in Link.java, so I'm now suspecting that the above
sets
the value, but nothing is using it yet....


A few more greps seem to suggest that max_prefetch relates to a
session
but link capacity relates to a destination, but it looks like they do
similar things (I think they buffer messages into an internal queue
on
the client runtime) but so far I've not found anything obvious about
producer capacity aside from the red herrings above, so I'm
suspecting
that there's no equivalent to qpid::messaging producer setCapacity in
JMS.


Sorry for rambling a bit, I hope that the train of thought is useful
and
perhaps someone who knows the code a bit better can confirm what I'm
seeing.

As an aside, the code base could do with a few more comments :-)

Let us know how you get on
Frase.


On 03/02/12 11:51, 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.

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.

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?

4) The same doc says prefetch is by default 1, 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)?


Thanks in advance for your feedback.

Kind regards,
Pavel



---------------------------------------------------------------------
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



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

Reply via email to