You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Gary Tully (JIRA)" <ji...@apache.org> on 2011/06/30 13:08:28 UTC
[jira] [Created] (AMQ-3384) destinationFilter could be generated
automatically by DemandForwardingBridgeSupport based on list of
dynamicallyIncludedDestinations
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: Gary Tully
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-3384) destinationFilter could be generated
automatically by DemandForwardingBridgeSupport based on list of
dynamicallyIncludedDestinations
Posted by "Dejan Bosanac (Resolved) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Assigned] (AMQ-3384) destinationFilter could be generated
automatically by DemandForwardingBridgeSupport based on list of
dynamicallyIncludedDestinations
Posted by "Dejan Bosanac (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dejan Bosanac reassigned AMQ-3384:
----------------------------------
Assignee: Dejan Bosanac (was: Gary Tully)
> 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.x
>
>
> 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