[
https://issues.apache.org/jira/browse/QPID-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426111#comment-13426111
]
Alan Conway edited comment on QPID-4100 at 9/20/12 3:30 AM:
------------------------------------------------------------
There are two obstacles to fixing this problem:
1. Currently queues, exchanges etc. are replicated using management queries and
events. To replicate links in the same way would require putting all the link
properties in to the management schema /including/ the password to use to
establish the link. That means anyone with permission to browse the management
objects could read the password which seems to be a security problem.
2. In creating a link to another cluster you need to specify *all* the
addresses of the cluster, otherwise you may not be able to start the link.
Currently links are created initially with a single target address, and
additional fail-over addresses can be added later. There is a mechanism to
automatically add fail-over addresses when a link connects to a cluster, but
this is only useful *if* the link successfully connects. If the initial target
of the link is down, then you are stuck. There's nowhere to get the additional
addresses from. Note this is not a problem if a virtual IP address is used.
was (Author: aconway):
There are two obstacles to fixing this problem:
1. Currently queues, exchanges etc. are replicated using management queries and
events. To replicate links in the same way would require putting all the link
properties in to the management schema /including/ the password to use to
establish the link. That means anyone with permission to browse the management
objects could read the password which seems to be a security problem.
2. In creating a link to another cluster you need to specify *all* the
addresses of the cluster, otherwise you may not be able to start the link.
Currently links are created initially with a single target address, and
additional fail-over addresses can be added later. There is a mechanism to
automatically add fail-over addresses when a link connects to a cluster, but
this is only useful *if* the link successfully connects. If the initial target
of the link is down, then you are stuck. There's nowhere to get the additional
addresses from.
> New HA federation links do not fail over
> ----------------------------------------
>
> Key: QPID-4100
> URL: https://issues.apache.org/jira/browse/QPID-4100
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Clustering
> Affects Versions: 0.17
> Reporter: Alan Conway
> Assignee: Cliff Jansen
>
> Given two new-HA clusters and a federation link between the primaries of each
> cluster:
> - if the source broker is killed, the route _does_ fail over to the new
> primary
> - if the destination broker is killed the route _is not_ re-created on the
> new primary
> Federation link and bridge information should be replicated to all cluster
> members so when a primary dies the backup that takes over can re-create links
> and bridges.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
