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: Federation and Queue Route Failover
Date Tue, 24 Apr 2012 17:38:50 GMT
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 

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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message