Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of gsim@redhat.com designates
 209.132.183.28 as permitted sender)
Message-ID: <4B262567.40405@redhat.com>
Date: Mon, 14 Dec 2009 11:45:43 +0000
From: Gordon Sim <gsim@redhat.com>
Organization: Registered Address: Red Hat UK Ltd, Amberley Place, 107-111
 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.,Registered in
 England and Wales under Company Registration No. 3798903,Directors: Michael
 Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: Behaviour when there're elements on the queue before
 instantiating
 the consumers
References: <002901ca7cb1$cac82390$60586ab0$@centeno@terra.com.br>
In-Reply-To: <002901ca7cb1$cac82390$60586ab0$@centeno@terra.com.br>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

On 12/14/2009 11:37 AM, Ac�cio Centeno wrote:
> Hi,
>
>
>
>                  We�re using QPid 0.5 and found a peculiar behaviour. We�re
> wondering why that�s happening.
>
>
>
>                  When the queue has elements, say 100, and we instantiate N
> consumers, say 5, only the first one receives those elements on the queue.
> Should we send new elements, they will be distributed among all the
> consumers, but the �old ones� will be delivered only to the first consumer
> (which we called internally �the hero� as it gets pretty stressed trying to
> come up with the backlog).
>
>
>
>                  Is this a bug, a known issue or not an issue at all but a
> required behavior? If it�s a bug, is it fixed on the 0.6 release?

Which broker & client(s) are you using?

For the c++ broker, when the first subscription is added it will take as 
many messages as it can get (subject to credit and ability to write to 
the socket) and thus (especially if the messages are relatively small) 
may get all 100 before the next subscription is ready to to compete with it.

You could try setting a finite credit window (default is infinite) to 
make the distribution fairer. Assuming you are using the c++ client, you 
do this by passing in SubscriptionSettings to the 
SubscriptionManager::subscribe() call.

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