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,
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.
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: [email protected]
For additional commands, e-mail: [email protected]
