Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Wed, 16 Feb 2011 14:02:57 +0000 (UTC)
From: "Timothy Bish (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: 
 <1055460544.20579.1297864977425.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <967787234.19530.1297825257636.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Commented: (AMQCPP-351) Using incorrect peer list in
 failover transport
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AMQCPP-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12995298#comment-12995298 ] 

Timothy Bish commented on AMQCPP-351:
-------------------------------------

Patch fails to set the initialized state in the FailoverTransport, corrected in fix.

> Using incorrect peer list in failover transport
> -----------------------------------------------
>
>                 Key: AMQCPP-351
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-351
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 3.2.4
>            Reporter: Adam Sussman
>            Assignee: Timothy Bish
>             Fix For: 3.3.0
>
>         Attachments: amqcpp-351.patch
>
>
> In the failover transport, the broker hands the client a list of known peer brokers the client can attempt upon connection failure.  In the Java client libs, this list of peers is obtained from the ConnectionControl object and that list is subject to various configuration controls on the broker.  The C++ client gets its list from the BrokerInfo object who's list is NOT controlled at all by broker settings and which also retains query string artifacts that should not be used (see AMQ-3124).
> The list of peers the C++ client is using is not correct and not under the same controls as the list the Java client is using. The C++ failover transport should be altered to use the same source of peer data as the Java client, the ConnectionControl object.
> In currently released versions (3.2.4 and older), the entire reconnect list comes from BrokerInfo.getPeerBrokerInfos.  In trunk, the list comes from BrokerInfo.getPeerBrokerInfos PLUS ConnectionControl.getReconnectTo.  However, the Java client gets its list from ConnectionControl.getConnectedBrokers plus ConnectionControl.getReconnectTo and does not use BrokerInfo at all.
> At a minimum, the usage of BrokerInfo.getPeerBrokerInfos needs to be removed in FailoverTransportListener.cpp and usage of getConnectedBrokers needs to be added to FailoverTransport.cpp:handleConnectionControl.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira