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

List:       activemq-dev
Subject:    [jira] [Created] (AMQ-4608) Network discovery creates looping connections to local broker
From:       "Andrea Marziali (JIRA)" <jira () apache ! org>
Date:       2013-06-27 15:35:20
Message-ID: JIRA.12655167.1372347265482.180036.1372347320248 () arcas
[Download RAW message or body]

Andrea Marziali created AMQ-4608:
------------------------------------

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


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] 

Configure | About | News | Add a list | Sponsored by KoreLogic