[jira] [Commented] (AMQ-6027) Dynamic network demand should support Virtual Destination consumers

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14997294#comment-14997294 ] 

ASF subversion and git services commented on AMQ-6027:
------------------------------------------------------

Commit cc81680e10e5c7140ec3e28091df23e9d3c3233b in activemq's branch refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=cc81680 ]

https://issues.apache.org/jira/browse/AMQ-6027

Adding support for consumers on virtual destinations to create network
demand. This behavior is turned off by default but can be enabled.

For example, if a consumer comes online for a queue that is part of a
VirtualTopic, this will cause a network of brokers to forward messages
because a demand subscription will be created. Same for if a consumer
comes online for a forwarded destination from a composite
destination.

There is also an option to enable flow based on the existence of a
virtual destination if the virtual destination is forwarding to a
Queue.

Full configuration instructions for this feature will be on the wiki page.


> Dynamic network demand should support Virtual Destination consumers
> -------------------------------------------------------------------
>
>                 Key: AMQ-6027
>                 URL: https://issues.apache.org/jira/browse/AMQ-6027
>             Project: ActiveMQ
>          Issue Type: New Feature
>          Components: Broker
>    Affects Versions: 5.12.1
>            Reporter: Christopher L. Shannon
>            Assignee: Christopher L. Shannon
>             Fix For: 5.13.0
>
>
> Currently the broker supports the notion of {{dynamicallyIncludedDestinations}}, where messages will only be sent across a network of brokers if there is a consumer that exists on that destination.  This is good because it reduces the amount of traffic if there are no consumers, however it doesn't take into account any virtual/composite destinations that might exist or the consumers on those virtual/composite destinations.  I'd like to be able to create demand and have messages flow based on Virtual Destination creation, either on start up or dynamically by the runtime configuration plugins, or by new consumers on a Virtual Destination.
> So for example, if there are two brokers networked and on Broker A messages are published to a topic, normally those messages only get passed to Broker B if there is a consumer on that topic when setting dynamicallyIncludedDestinations to true.  I want to have an option so that a virtual destination setup on Broker B that forwards that topic to a queue will trigger messages to start flowing from Broker A to Broker B.  
> Messages could start flowing either simply based on the existence of the Virtual Destination (likely used for the case of a topic forwarding to a queue, so messages accumulate on the queue) or based on there being a consumer on the forwarded destination (likely used for the case of a queue forwarding to a topic). 
> I've done some prototyping work here already and my plan is to keep track of Virtual Destination consumers (configurable by the existence of the virtual destination or by the fact that a real consumer exists on it) and to create a new advisory topic where the broker can publish consumer advisories to.  The prefix could be called something like:
> ActiveMQ.Advisory.VirtualDestination.Consumer.Topic
> ActiveMQ.Advisory.VirtualDestination.Consumer.Queue
> Advisory messages can be sent either when virtual destinations are created/destroyed (kind of a dummy consumer) or when a real consumer comes online for a virtual destination.  Then a remote broker could optionally listen for those advisory messages and create or destroy a DemandSubscription, just like is currently done for normal consumers.
> The default behavior out of the box would be to keep this behavior turned off, but it could optionally be turned on through configuration.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)