Major Description
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.
