What are Virtual Destinations in ActiveMQ and how do they work?

Solution Verified - Updated -

Environment

  • Red Hat A-MQ
    • 6.x

Issue

  • What are Fuse Message Broker Virtual Destinations and how do they work?
  • What is the purpose of ActiveMQ Virtual Destinations?
  • How does virtual destinations help in the scenario of Durable subscription & network of brokers

Resolution

Virtual Destinations are logical destinations (i.e. Queues or Topics) that map onto one or more physical destinations. Their purpose is to overcome some load balancing/HA limitations with durable subscribers.

How it works:
1) Producer sends to the logical topic "VirtualTopic.T"
2) Consumer A can consume from the "VirutalTopic.T" as normal Topic consumer.
3) Consumers B & C can also consume, via a dedicated physical queue linked to the logical topic.

 
[producer] --> [VirtualTopic.T] --> [consumerA]
                                --> [VirtualQueueConsumer.VirtualTopicT] --> [ConsumerB]
                                                                         --> [ConsumerC]

Note: "VirtualQueueConsumer.VirtualTopicT" is a physical queue. This means you can have a pool of consumers consuming from the queue, allowing you to overcome some of the limitations of durable subscribers.
Configuration of virtual destinations is doen via the brokers /conf/activemq.xml:

<destinationInterceptors> 
   <virtualDestinationInterceptor> 
     <virtualDestinations> 
        <!-- deliver traffic from virtual topic T to all subscribers to destinations matching the prefix "VirtualQueueConsumer.*" (queue or topic) -->
        <virtualTopic name="VirtualTopic.T" 
                    prefix="VirtualQueueConsumer.*." /> 
     </virtualDestinations> 
    </virtualDestinationInterceptor> 
   </destinationInterceptors> 
 </broker>

Durable subscribers behave a little differently across a cluster of ActiveMQ brokers. The two main issues surround messages getting stuck on other brokers in the network after a durable subscriber has disconnected and reconnected to a different broker in the network without fully unsubscribing. The reasons for disconnecting/reconnecting can be voluntary (where the subscriber is using the failover transport), or involuntary (one of the brokers in the cluster fails).
For example, if you have two brokers A and B networked together in both directions to form a cluster, and a durable subscriber connects to broker B, a producer P on broker A will have its messages properly forwarded to broker B and the durable subscriber. However, if the subscriber disconnects and reconnects to broker A, any messages sent by P while the subscriber was away will be stuck on B until the subscriber reconnects to B.
The solution is to use Virtual Destinations

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments