activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Tully (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMQ-3384) destinationFilter could be generated automatically by DemandForwardingBridgeSupport based on list of dynamicallyIncludedDestinations
Date Thu, 30 Jun 2011 11:08:28 GMT
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

        

Mime
View raw message