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 Sat, 04 Aug 2012 10:03:42 GMT

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

One more possibly relevant detail in this sorry tale of woe.....

The federation links that we are using are source/push routes e.g. set 
up using qpid-route -s

I wonder if that would have any bearing, so the scenario is really a 
bursty producer much like the client-producer example, writing to 
amq.match on a broker co-located on the same host, which has a queue 
route federated to another broker on a different host, which has a 
potentially slow consumer with possibly/probably too much prefetch 
allocated.

So using source routes is it likely then that an end consumer requesting 
too much capacity could cause a problem for the first broker??? It (sort 
of) seems odd because if the federation uses unreliable messaging then 
surely that should protect the source broker from the excess capacity - 
but it's very definitely the source broker associated with the producer 
and not the destination broker where be see the issue.


Hmmm I wonder Gordon. You've previously said that "federation 
subscriptions do use infinite credit" , so with a source route the 
bridge would behave essentially like a consumer of the queue actually 
deployed on the source broker, so if there were any problems at all in 
its communications to the destination broker then it would behave 
exactly like my slow consumer scenario would it not and its memory would 
grow due to the infinite credit? Now the fact that it's unreliable 
messaging might help, but is it correctly implemented for source routes? 
You've said before that source routes are the path less travelled, so 
that feels plausible (especially given my experiences with qpid::client 
:-))?

What do you think - do you have any evidence your side or am I just 
clutching at straws??

Frase




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


Mime
View raw message