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
