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