On 08/04/2012 11:03 AM, Fraser Adams wrote:
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???
Any subscriber requesting a large amount of prefetch could potentially
cause memory growth in the broker they have subscribed to, particularly
if they are slow to process such prefetched messages.
The slowness of a consumer on a queue on the downstream (i.e.
destination) broker to which messages from the upstream (i.e. source)
broker are routed doesn't directly affect the subscription on the
upstream broker.
If it is a slow consumer problem, then it would imply that it is the
handling of messages from the source broker (i.e. routing them through
the amq.match exchange), that is the problem. Comparing the stats from
the source queue and the target exchange might show something if that
were the case (i.e. many more messages delivered from the queue than
routed through the exchange; that of course may require compensating for
the point you start at)
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,
Depends on what you mean; the route appears to the broker as a
subscription from the queue. The push route mainly affects the manner in
which the subscription is issued (it is 'forged' by the broker who sends
the request to itself as if it were the remote peer sending it).
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?
The selection of the accept mode is the same code in both types of
routes, so on the face of it at least I can't see why there would be any
difference there.
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??
I can't see any evidence that source routes would cause the behaviour
you are seeing.
If you can reproduce easily, I would suggest (a) once you start seeing
the excessive growth, kill and then re-establish the route and see
whether that resets the growth, (b) compile a later broker in a working
directory somewhere (no need to install) and see if that shows the same
thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
