[
https://issues.apache.org/jira/browse/AMQ-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dejan Bosanac resolved AMQ-3384.
--------------------------------
Resolution: Fixed
Fix Version/s: (was: 5.x)
5.6.0
Fixed with svn revision 1205508
> destinationFilter could be generated automatically by
> DemandForwardingBridgeSupport based on list of dynamicallyIncludedDestinations
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-3384
> URL: https://issues.apache.org/jira/browse/AMQ-3384
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 5.5.0
> Environment: large network of brokers
> Reporter: Gary Tully
> Assignee: Dejan Bosanac
> Labels: activemq, advisory, load, networks
> Fix For: 5.6.0
>
>
> Digging into the Advisory messages we found one "missing" feature.
> Network connector creates listener on Advisory topics on remote broker (and
> contrary for duplex NC). Listener created for topics like this:
> DemandForwardingBridgeSupport.java:{code}
> 368 String advisoryTopic =
> AdvisorySupport.CONSUMER_ADVISORY_TOPIC_PREFIX +
> configuration.getDestinationFilter();
> 369 if (configuration.isBridgeTempDestinations()) {
> 370 advisoryTopic += "," +
> AdvisorySupport.TEMP_DESTINATION_COMPOSITE_ADVISORY_TOPIC;
> 371{code} }
> This equals to the following:
> {code}
> ActiveMQ.Advisory.Consumer.>, ActiveMQ.Advisory.TempQueue,
> ActiveMQ.Advisory.TempTopic{code}
> So that, broker will be subscribed to Consumer Advisory messages for ALL
> queues and topics on remote broker. But really, broker interests only for
> those defined in dynamicallyIncludedDestinations. We have about 80 brokers
> connected to central. So, ALL of them subscribed to Consumer Advisory
> messages for ALL queues and topics. This subscriptions produce huge "flood"
> traffic and creates unnecessary central broker load. This could lead to
> connection timeouts, reconnects and as result - produce yet more advisory
> traffic. If brokers have tow network connectors, number of subscriptions,
> traffic, load will be double. After some times of work all that central
> broker do is dispatching advisory messages.
> There is workaround. We can use "destinationFilter" attribute of
> networkConnector element to specify "advisory topic suffix". So, that broker
> will be subscribed only to
> {code}
> ActiveMQ.Advisory.Consumer.[destinationFilter], ActiveMQ.Advisory.TempQueue,
> ActiveMQ.Advisory.TempTopic{code}
> We have checked that this attribute works for duplex and "non-duplex"
> connectors.
> The problem with this workaround is that we have to follow very specific
> syntax for destinationFilter.
> For example, if we have tow queues defined in
> dynamicallyIncludedDestinations, we have to write something like:
> {code}
> <networkConnector uri="static:(tcp://host)"
> destinationFilter="Queue.outbound,ActiveMQ.Advisory.Consumer.Queue.inbound" >
> <dynamicallyIncludedDestinations>
> <queue physicalName="outbound"/>
> <queue physicalName="inbound"/>
> </dynamicallyIncludedDestinations>
> </networkConnector>{code}
> As you can see, syntax of "destinationFilter" is not trivial )
> Feature we would like to have is that destinationFilter could be generated
> automatically by DemandForwardingBridgeSupport based on list of
> dynamicallyIncludedDestinations. So that we don`t have to specify
> "destinationFilter" at all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
