qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fallon, Richard" <richard.fal...@atos.net>
Subject Federation and Queue Route Failover
Date Mon, 23 Apr 2012 12:56:45 GMT


I have been successfully using a federated network of Apache Qpid 
brokers for some time now, we have had some problems along the way but 
generally everything is working very well. 

I have a requirement to introduce more resilience to parts of the 
network. The (simplified) solution is this 

1. SOURCE -> DESTINATION A : source sends messages to destination A 
3. SOURCE -> DESTINATION B : source sends messages to destination B 

We have a piece of hardware between the brokers so we refer to the 
destination with a generic value (e.g. DESTINATION) and this returns the

correct hostname of the destination (i.e. A OR B). 

The above scenario works very well if the source is an amqp publisher, 
e.g. a JMS Client using AMQP syntax. 

However if the source and destinations are qpid brokers and connected 
via a queue route this does not work. 

Let me try and explain my rather bizarre results... 

1. SOURCE BROKER -> DESTINATION BROKER (hostname = A) - connected 
3. Load Balancer now returns hostname=B for DESTINATION BROKER 
4. SOURCE BROKER shows connection refused to DESTINATION BROKER 

So maybe I can understand the above, the SOURCE has created a socket 
connection to hostname A, and is not releasing it. 

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. It is like the SOURCE broker is 
still trying to connect to the DESTINATION (hostname = A), even after 
restart. That suggests to me that Qpid persists some connection 
information throughout a restart. 

Does this sound plausible? If so where would the connection info be 
stored? FYI - I'm using version 0.8. 

Thanks in advance 


 <<Picture (Metafile)>> 
Richard Fallon
01928 594109
 <<Picture (Metafile)>> 

Atos and Atos Consulting are trading names used by the Atos group.  The following trading
entities are registered in England and Wales:  Atos IT Services UK Limited (registered number
01245534), Atos Consulting Limited (registered number 04312380) and Atos IT Solutions and
Services Limited  (registered number 01203466) The registered office for each is at 4 Triton
Square, Regents Place, London, NW1 3HG. The VAT No. for each is: GB232327983

This e-mail and the documents attached are confidential and intended solely for the addressee,
and may contain confidential or privileged information.  If you receive this e-mail in error,
you are not authorised to copy, disclose, use or retain it.  Please notify the sender immediately
and delete this email from your systems.   As emails may be intercepted, amended or lost,
they are not secure.  Atos therefore can accept no liability for any errors or their content.
 Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission
is virus-free and can accept no liability for any damages resulting from any virus transmitted.
The risks are deemed to be accepted by everyone who communicates with Atos by email.

View raw message