qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DISPATCH-818) Honor failoverList provided by connected brokers
Date Tue, 19 Sep 2017 17:40:00 GMT

    [ https://issues.apache.org/jira/browse/DISPATCH-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16172064#comment-16172064

ASF subversion and git services commented on DISPATCH-818:

Commit af96b23fefe0076391db35d31d612a1ab5e6f4a2 in qpid-dispatch's branch refs/heads/master
from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=af96b23 ]

DISPATCH-818 - Added connection info list to the connector which stores the initial connection
information and the backup connection information
1. If the primary connection goes down, the primary and the backup connections will be tried
in quick succession
2. If the new backup connection does not provide failover-server-list, the list on the server
is cleaned up to contain only the one pertinent connection info.
3. The connection info list always has at least one element in it which represents the initial
successful connection information

(cherry picked from commit 2fc9e285f92d96f7d6c5a4e9e36bf356ab7cc256)

> Honor failoverList provided by connected brokers
> ------------------------------------------------
>                 Key: DISPATCH-818
>                 URL: https://issues.apache.org/jira/browse/DISPATCH-818
>             Project: Qpid Dispatch
>          Issue Type: Bug
>          Components: Container
>    Affects Versions: 0.8.0
>            Reporter: Ganesh Murthy
>            Assignee: Ganesh Murthy
>             Fix For: 1.0.0
> When a router makes a connection to a broker (using a configured connector), the broker
may provide alternate connection information for use in a failure scenario. The router must
honor this alternate connection data when the primary connection is lost.
> For example, if the router opens a connection to the broker and the broker responds with
an open frame like the following - 
> {noformat}
> [0x7fc8b000a3e0]:0 <- @open(16) [container-id="Router.A", max-frame-size=16384, channel-max=32767,
idle-time-out=8000, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router",
:version="1.0.0", :"failover-server-list"=[{:"network-host"="second-host", :port="25000"},
{:"network-host"="third-host", :port="5671", :scheme="amqps"}]}]
> {noformat}
> notice that the broker sends a failover-server-list of 
> {noformat}
> "failover-server-list"=[{:"network-host"="second-host", :port="25000"}, {:"network-host"="third-host",
:port="5671", :scheme="amqps"}]
> {noformat}
> The router should store this alternate connection information and retry these hosts when
the original connection goes down.
> The following should be the order of operations
>  - The original connection goes down, try connecting with the original connection information
one more time. If that failed, try connecting with the alternate connection information. If
the original and the alternate failed, keep going round robin between alternate and original
until you get a successful hit.
> - If there is no alternate connection information, keep on trying to connect using the
original connection information (which is what is currently happening).

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message