[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    [jira] [Updated] (AMQ-4608) Network discovery creates looping connections to local broker
From:       "Andrea Marziali (JIRA)" <jira () apache ! org>
Date:       2013-06-28 8:52:19
Message-ID: JIRA.12655167.1372347265482.183095.1372409539917 () arcas
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/AMQ-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Andrea Marziali updated AMQ-4608:
---------------------------------

    Attachment: patch.diff

Diff against AMQ trunk
                
> Network discovery creates looping connections to local broker
> -------------------------------------------------------------
> 
> Key: AMQ-4608
> URL: https://issues.apache.org/jira/browse/AMQ-4608
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.8.0
> Reporter: Andrea Marziali
> Attachments: patch.diff
> 
> 
> Hello,
> please consider this store and forward network of broker scenario:
> -------- activemq.xml snippet ----------
> If you're using a multicast discovery in your network of broker you may have a \
> scenario like this one: <!-- Transport protocol -->
> 	<transportConnectors>
> 		<transportConnector name="openwire" uri="nio://host:port?useQueueForAccept=false" \
> discoveryUri="multicast://default" />			  </transportConnectors>
> 	<!-- Broker network connectors -->	
> 	<networkConnectors>
> 		<networkConnector name="bridgeConnector" uri="multicast://default" 		
> 			decreaseNetworkConsumerPriority="true" 
> 			userName="system" password="manager" 
> 			suppressDuplicateTopicSubscriptions="true" \
> suppressDuplicateQueueSubscriptions="true">				  <excludedDestinations>
> 				<queue physicalName=">"/>
> 			</excludedDestinations>
> 		</networkConnector>
> 	</networkConnectors>
> --------------------------------------
> When adding network connectors using multicast discovery, ActiveMQ is actually \
> checking if you're not connecting to the local broker itself (in order to avoid \
> loops). This is implemented in the BrokerService class
> ------------------- BrokerService.java extract ---------------------
> connector.setLocalUri(uri);
> // Set a connection filter so that the connector does not establish loop
> // back connections.
> connector.setConnectionFilter(new ConnectionFilter() {
> public boolean connectTo(URI location) {
> List<TransportConnector> transportConnectors = getTransportConnectors();
> for (Iterator<TransportConnector> iter = transportConnectors.iterator(); \
> iter.hasNext();) { try {
> TransportConnector tc = iter.next();
> if (location.equals(tc.getConnectUri())) {   
> return false;
> }
> } catch (Throwable e) {
> }
> }
> return true;
> }
> });
> networkConnectors.add(connector);
> -------------------------------------------------------------
> Now, if the connector uri (tc.getConnectUri()) contains parameters as showed above \
> (?useQueueForAccept=true) you will have a comparison between the URI without \
> parameter coming from the multicast discovery and the one with parameter coming \
> from the connector configuration. Following the configuration example below you \
> will compare "nio://host:port" with "nio://host:port?useQueueForAccept=false". This \
> obviously won't work and you will open a network connection with the broker itself, \
> resulting having duplicate messages. One idea to fix the bug is to compare URIs \
> without parameters. Could you please take this bug into account and propose a fix?
> Thanks in advance
> Andrea

--
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


[prev in list] [next in list] [prev in thread] [next in thread]