You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2013/07/08 21:57:49 UTC
[jira] [Commented] (AMQ-4608) Network discovery creates looping
connections to local broker
[ 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