activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrea Marziali (JIRA)" <>
Subject [jira] [Created] (AMQ-4608) Network discovery creates looping connections to local broker
Date Thu, 27 Jun 2013 15:35:20 GMT
Andrea Marziali created AMQ-4608:

             Summary: Network discovery creates looping connections to local broker
                 Key: AMQ-4608
             Project: ActiveMQ
          Issue Type: Bug
          Components: Transport
    Affects Versions: 5.8.0
            Reporter: Andrea Marziali


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 -->
		<transportConnector name="openwire" uri="nio://host:port?useQueueForAccept=false" discoveryUri="multicast://default"

	<!-- Broker network connectors -->	
		<networkConnector name="bridgeConnector" uri="multicast://default" 		
			userName="system" password="manager" 
			suppressDuplicateTopicSubscriptions="true" suppressDuplicateQueueSubscriptions="true">
				<queue physicalName=">"/>


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

------------------- extract ---------------------
        // 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 =;
                        if (location.equals(tc.getConnectUri())) {   
                            return false;
                    } catch (Throwable e) {
                return true;


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


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:

View raw message