[
https://issues.apache.org/jira/browse/AMQ-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13702347#comment-13702347
]
Timothy Bish commented on AMQ-4608:
-----------------------------------
Have you tested a recent SNAPSHOT build, this appears to be a duplicate of
AMQ-4408. If you still have an issue please attach a unit test to reproduce.
> 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
