activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-6027) Dynamic network demand should support Virtual Destination consumers
Date Mon, 09 Nov 2015 20:29:11 GMT

    [ 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)

Mime
View raw message