qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: more memory "leak" woes.
Date Fri, 03 Aug 2012 13:38:28 GMT
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)?

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

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.

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

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

View raw message