qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Conway (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (QPID-4100) New HA federation links do not fail over
Date Wed, 19 Sep 2012 16:31:08 GMT

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


Mime
View raw message