Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 54CE5D6EC for ; Thu, 12 Jul 2012 11:58:46 +0000 (UTC) Received: (qmail 83899 invoked by uid 500); 12 Jul 2012 11:58:46 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 83536 invoked by uid 500); 12 Jul 2012 11:58:42 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 83510 invoked by uid 99); 12 Jul 2012 11:58:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jul 2012 11:58:41 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of zhihua.che@gmail.com designates 209.85.160.42 as permitted sender) Received: from [209.85.160.42] (HELO mail-pb0-f42.google.com) (209.85.160.42) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jul 2012 11:58:35 +0000 Received: by pbbrp12 with SMTP id rp12so3247739pbb.15 for ; Thu, 12 Jul 2012 04:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=nWd/g54xytMoVoEJbGeNB06+Uoj3IfoEPxtbu12bQxA=; b=zu8/TCrIfaVlEYSxBKLDFdn6hPhnDZ8ynnQd/cIKsPNtUCvsNKpH9C9qMvkMvxPLJ5 PS8ELiC3VI1VWlVCKaVzHrR+HlKywE4W3nV9/KWncD+ulFLesusVb5SOYFvES6krKngk M8/B5xQ4FW6ivhFUUdnvq5Mk0ej4Vntn/jKz5pFwKex73y5+9I0AajqcoRrqQyERkPUs 658VMO9R8aZaAbHo5QaMC1SfDB5k+nWA935zpYRFsZ+jlLwgoM2vF372BovZJqDMrL81 x2GyULuxBj6M36Dhl1KVOoM0DyZomMmHdJa1Ny7fu9jcJ+4/p6U6XNcUK+sAN/N0SaUI FOOg== MIME-Version: 1.0 Received: by 10.68.223.138 with SMTP id qu10mr5095091pbc.50.1342094294753; Thu, 12 Jul 2012 04:58:14 -0700 (PDT) Received: by 10.142.52.9 with HTTP; Thu, 12 Jul 2012 04:58:14 -0700 (PDT) In-Reply-To: <4FFEB503.70607@redhat.com> References: <4FFEB503.70607@redhat.com> Date: Thu, 12 Jul 2012 19:58:14 +0800 Message-ID: Subject: Re: what does mean 'Capacity'? From: Zhihua Che To: users@qpid.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org 2012/7/12 Gordon Sim : > On 07/12/2012 03:36 AM, Zhihua Che wrote: >> >> hi, >> >> I got confused with the term of 'capacity' of the sender and >> receiver. > > > Essentially 'capacity' restricts the number of 'buffered' messages. In the > case of the sender, this is messages that have been sent but not yet > confirmed by the broker. In the case of the receiver this is the number of > messages the broker can pre-emptively send to the client - what is often > known as 'prefetch', i.e. messages send by the broker before the application > has actually fetched them, in anticipation of- and in order to speed up- > subsequent fetches. > > >> In my app, I create a queue and a sender and a receiver bound with >> it. >> I also set both the capacity of the sender and receiver as 100. >> Through qpid-tool, I find that, every time the receiver receives >> one message from the queue, a field named 'acquires' of the queue is >> increased by one. > > > Right, that indicates the broker allocating a message to the consumer. > > >> When the 'acquires' number reaches the 100, my app cannot get >> message from the queue any more. > > > What do you mean here? Certainly that number should not go up further > without the receiver calling fetch(), but the receiver should certainly be > able to fetch() more messages. The capacity 'window' is moved as messages > sent by the broker are handed off to the application in response to fetch() > calls. > > >> So, what does the term 'capacity' and the field 'acquires' mean? > > > Hopefully the description of capacity above will make sense. The 'acquires' > stat in management tracks the number of message 'allocations'. For competing > consumers, each message is given to only one consumer - the consumer is > considered to have 'acquired' the message. > > >> I noticed that, in qpid-tool, another field 'release' which is >> actually above 'acquires' is always 0, is it right? > > > Yes, unless you either release messages explicitly (through > Session::release()) or end a session without acknowledging messages, there > will be no released messages. > > Releasing a message is a mechanism for allowing a message acquired by one > consumer to be returned to the available state and re-acquired (potentially > by another consumer). > > >> As for my code, I use c++ client and qpid::messaging api. I send >> the message using sender.send(msg, true), and fetch message with >> fetch(msg, Duration::IMMEDIATE), and acknowledge by call >> session.acknowledge(); > > > If sending synchronously (i.e. specifying true for the second parameter to > send()), the senders capacity is of no real significance as you are blocking > until that send has completed. (In effect the used capacity will never be > greater than 1). > > If you are finding that you stop being able to fetch() messages even when > there are some available on the queue, please provide a bit more detail on > the receiving application, ideally a reproducer. > > Hope this helps... > > Thanks for your detailed reply and it helps a lot. But I still cannot understand the behavior of my app. Precisely, there are two processes, a producer (sender) and a consumer (receiver). Before sending messing, sender.setCapacity(100) and receiver.setCapacity(100) are called. Then, sender.send(msg, true) is used to send message while receiver.fetch(msg, Duration::IMMEDIATE) is used to fetch message. The receiver also print the message content every time when it fetches a message successfully. The strange thing is the receiver cannot fetch any message from the queue after it receives the 100 messages. And the sender process still continues, that is, not blocked by the call to send(msg, true). --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@qpid.apache.org