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 fraser.adams@blueyonder.co.uk
 designates 81.103.221.47 as permitted sender)
Message-ID: <501BD234.8010305@blueyonder.co.uk>
Date: Fri, 03 Aug 2012 14:29:24 +0100
From: Fraser Adams <fraser.adams@blueyonder.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: more memory "leak" woes.
References: <4F4F8FE4.9020404@redhat.com> <501BAB24.3020108@blueyonder.co.uk>
 <501BBBE0.5090305@redhat.com> <501BC5A8.4000204@blueyonder.co.uk>
 <501BCA5C.1040802@redhat.com> <501BCA99.6040003@redhat.com>
In-Reply-To: <501BCA99.6040003@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 03/08/12 13:56, Gordon Sim wrote:
> On 08/03/2012 01:55 PM, Gordon Sim wrote:
>> On 08/03/2012 01:35 PM, Fraser Adams wrote:
>>>      subscription = subscriptions.subscribe(*this, queue);
>>>
>>> subscription.setFlowControl(FlowControl::messageWindow(100)); // Why
>>> doesn't this work :-( ???
>>>      subscription.setAutoAck(10);
>>
>> When you say it didn't work, what exactly do you mean? That it behaved
>> like the messaqeCredit() call? or that it didn't restrict the window?
>>
>> Try setting the option on subscribe, rather than after it. E.g.
>>
>>    subscription = subscriptions.subscribe(*this, queue,
>> SubscriptionSettings(FlowControl::messageCredit(100)));
>
> Sorry! That should read messageWindow() of course!!
>
So yeah when I tried
subscription.setFlowControl(FlowControl::messageWindow(100));

It behaved as if I hadn't done anything and my memory consumption grew 
out of control.

I've now tried

subscription = subscriptions.subscribe(*this, queue, 
SubscriptionSettings(FlowControl::messageWindow(100)));
subscription.setAutoAck(10);

As you suggested here and both qpidd and client-consumer seem happier - 
qpidd is on ~320M and client-consumer is on ~220M SHR according to top 
and are both fairly stable.

Any idea why calling setFlowControl() on the subscription didn't work? 
It seems confusing to have a method call that doesn't appear to work...

On my other questions - so now I've got flow control working can you 
suggest how to configure a qpid::client consumer to use unreliable 
messaging?

So if I can configure client-consumer with unlimited flow control and 
unreliable messaging will that be a fair emulation of a broker bridge 
with a slow consumer hanging off it. I might then be able to try it with 
my 0.12 broker then a 0.8 broker and see if they behave differently - if 
they do then that just *might* be our smoking gun - what do you think 
(unless you already know the answer).

Cheers,
Frase


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org