Richard's issue does seem weird.
I note that he's using source routes, given his comment.
qpid-config -s queue add DESTINATION SOURCE amq.match queue_name
I'm not at all clear how qpid/amqp behaves through a hardware load
balancer. I did wonder if there might be an issue whereby the federating
bridge talks to the balancer with a hostname/servicename that resolves
to an IP address and whether somehow the IP is cached in the broker so
when the connection fails it uses the IP rather than doing another DNS
lookup which ought to resolve to the failover address, however Richard's
other observation seems plain bizarre "However if I stop and start the
SOURCE broker, and re add the queue route using SOURCE and DESTINATION I
still get the connection refused message, but hostname = B is running"
Richard out of curiosity in this scenario can you ping hostname = B? can
you actually connect to broker B using an ordinary client (you mentioned
in your original post The above scenario works very well if the source
is an amqp publisher, e.g. a JMS Client using AMQP syntax.) so to be
clear does hostname = B only seem "invisible" to a queue route (I'm just
trying to narrow if it's a bridge issue or some weirdness with the load
balancer's DNS resolver).
Surely if source routes are being used stopping and starting the source
broker would remove the federation link (Richard mentions he's not using
durable anything).
I'm interested in this sort of thing too, has anyone else had experience
running federated links through a hardware load balancer (we were
contemplating Cisco's Global Site Selector) but I've no experience of
this sort of technology so I'm wondering whether it's actually a viable
approach.
As a related aside as far as I'm aware qpid has a failover mechanism
that uses amqp heartbeats IIRC, from the perspective of amqp client
software I believe that this works by specifying a broker list in the
connection URL, however it's not clear how (or even whether) it's
possible to set up failover on federated links. With source routes I'd
have *assumed* that the bridge code would behave rather like any old
producer client so if a destination broker fails it (logically at any
rate) ought to be able to fail over to an alternate destination broker,
but qpid-route certainly doesn't suggest that broker lists can be used.
So bottom line is that I'm as interested as Richard in strategies for
fail over in a federated architecture (I don't want to use clustering).
On 23/04/12 16:04, Gordon Sim wrote:
On 04/23/2012 03:32 PM, rfallon wrote:
I'm not actually specifying the route as durable.
I wouldn't expect the information to be persisted in that case... what
is the output for qpid-route link list SOURCE?
Maybe it would be worth turning on debug logging to see if that gives
any other clues (e.g. --log-enable notice+ --log-enable debug+:Link
--log-enable debug+:Bridge). If you do that after restarting the
source, what do you see?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
