qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: more memory "leak" woes.
Date Fri, 03 Aug 2012 14:05:35 GMT
On 03/08/12 14:38, Gordon Sim wrote:
> On 08/03/2012 01:35 PM, Fraser Adams wrote:
>> So if the "unreliable message" behaviour isn't behaving as expected in
>> earlier brokers (say 0.8) and we have a slow consumer hanging off the
>> other side of a federated link, then are you suggesting that this just
>> might be the cause of our woes?
>
> I'm not exactly sure where the problem is. Is it the 'upstream' broker 
> that is growing? i.e. the one the publisher is connected to? Or is it 
> the broker 'downstream' of the federation link (the one the consumer 
> is connected to)?

It's the broker that the publisher is connected to that is growing. As I 
mentioned previously the really weird thing is that it only seems to 
happen when that broker is co-located with the publisher. What's 
especially weird is that things are mostly OK. most of our topology 
still has the producer and first broker co-located, but we had a 
particularly high rate (and quite bursty) producer that was giving us 
problems and the work around was to point it to a remote broker. I 
suspect that we're seeing it again because many of our other producers 
are starting to increase their rate now.

Our theory has been that perhaps the network was doing just enough to 
flatten out the burstiness. The test clients are set up to deliver 
bursts then sleep as this is quite close to what our real producers do.

>
>> At this stage having a
>> good analysis and understanding is probably most important - so if you
>> can help me enable flow control (and suggest how I'd try unreliable
>> messaging using qpid::client too if possible) in the client-consumer I
>> posted that would be really helpful.
>
> subscription = subscriptions.subscribe(*this, queue,
>   SubscriptionSettings(FlowControl::messageWindow(100),
>   ACCEPT_MODE_NONE));
>
> Would give a flow controlled, unreliable subscription. However simply 
> setting the ACCEPT_MODE_NONE with FlowControl::unlimited() in the 
> qpid::client API should prevent build up of messages through delivery 
> records at all.
Thanks, I'll try that out.

>
>> If I can get evidence to suggest that the federation "unreliable links"
>> behaviour isn't as effective at mitigating this in 0.8 as it is in later
>> brokers that would be useful, as I say I keep arguing that we should be
>> upgrading to something newer.
>
> I've had a scan through the svn logs and I don't see anything 
> obviously broken in 0.8; the lines that allow the message to be 
> released are in there. However a lot has changed since and many other 
> things could interact.
It's a pity that there's nothing obvious. I'll try your suggestion for 
unreliable messaging then I might set my box back to 0.8 to see if it 
behaves any differently than 0.12.

BTW do you know of a good way to allow multiple broker versions to 
co-exist on the same box (short of virtualisation). I always seem to 
need to completely uninstall one version before I can install another 
due to library dependencies. I guess that I could set up a chroot jail, 
but I was wondering if there's a simpler approach?


Frase.







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


Mime
View raw message