qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DISPATCH-818) Honor failoverList provided by connected brokers
Date Fri, 15 Sep 2017 19:27:01 GMT

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

ASF GitHub Bot commented on DISPATCH-818:

Github user ted-ross commented on a diff in the pull request:

    --- Diff: src/connection_manager.c ---
    @@ -633,7 +633,46 @@ qd_error_t qd_entity_refresh_listener(qd_entity_t* entity, void *impl)
     qd_error_t qd_entity_refresh_connector(qd_entity_t* entity, void *impl)
    -    return QD_ERROR_NONE;
    +    qd_connector_t *ct = (qd_connector_t*) impl;
    +    if (DEQ_SIZE(ct->conn_info_list) > 1) {
    +        qd_failover_item_list_t   conn_info_list = ct->conn_info_list;
    +        qd_failover_item_t *item = DEQ_HEAD(conn_info_list);
    +        //
    +        // As you can see we are skipping the head of the list. The
    +        // first item in the list is always the original connection information
    +        // and we dont want to display that information as part of the failover list.
    +        //
    +        char failover_info[250];
    --- End diff --
    Having a fixed-length string and later using strcat (not strncat) causes this to be a
buffer/stack overflow vulnerability.  Please ensure that the failover_info buffer cannot be

> 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