At present, if connections between brokers fail they will periodically
attempt to reconnect on the defined host and port. A broker now also
sends a list of known-hosts during the connection handshaking.
As part of some work on asynchronous state replication between clusters
I have committed a patch (r736354) that uses the addresses supplied as
known-hosts when attempting to re-establish a link. I encountered a few
issues that I thought were worth mentioning:
(i) The host and port combination is used as a key in the link registry.
If either of these are changed the link registry has to be updated so
that the link can be notified of establishment of a connection (which is
signaled to the registry using the host:port key).
(ii) The host and port are immutable on the management object for a link
and are used in the indexing of the object. I didn't change this which
means that the host and port properties don't necessarily correspond to
those used in the current connection. To make up for that I set the
error state to indicate that the link has failed over to a specified
address.
(iii) This behaviour will currently be triggered whenever the broker
supplies tcp addresses in the known-hosts list. At present it does so
regardless of whether its part of a cluster. The cluster module allows
the URL used to be overridden and I've added a similar option to the
broker options (it also allows an empty list to be sent be specifying
'none').
(iv) One important limitation at present is that any changes to the
cluster membership after a federation link has been established to that
cluster will not yet be picked up. Thus when adding a member, on a new
host and port combination, to a cluster the federation links would need
to be recreated.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
