40 lines
2.1 KiB
Markdown
40 lines
2.1 KiB
Markdown
|
Virtual Topics
|
||
|
|
==============
|
||
|
|
|
||
|
|
Virtual Topics (a specialisation of virtual destinations) in ActiveMQ 5.x typically address two different but related
|
||
|
|
problems. Lets take each in turn:
|
||
|
|
|
||
|
|
Shared access to a JMS durable topic subscription
|
||
|
|
-------------------------------------------------
|
||
|
|
With JMS1.1, a durable subscription is identified by the pair of clientId and subscriptionName. The clientId
|
||
|
|
component must be unique to a connection on the broker. This means that the subscription is exclusive. It is
|
||
|
|
not possible to load balance the stream of messages across consumers and quick failover is difficult because the
|
||
|
|
existing connection state on the broker needs to be first disposed.
|
||
|
|
With virtual topics, each subscription's stream of messages is redirected to a queue.
|
||
|
|
|
||
|
|
JMS2.0 adds the possibility of shared subscriptions with new API's that are fully supported in Artemis.
|
||
|
|
Secondly, Artemis uses a queue per topic subscriber model internally and it is possibly to directly address the
|
||
|
|
subscription queue using it's Fully Qualified Queue name (FQQN).
|
||
|
|
|
||
|
|
For example, a default 5.x consumer for topic `VirtualTopic.Orders` subscription `A`:
|
||
|
|
```
|
||
|
|
...
|
||
|
|
Queue subscriptionQueue = session.createQueue("Consumer.A.VirtualTopic.Orders");
|
||
|
|
session.createConsumer(subscriptionQueue);
|
||
|
|
|
||
|
|
```
|
||
|
|
would be replaced with an Artemis FQQN comprised of the address and queue.
|
||
|
|
```
|
||
|
|
...
|
||
|
|
Queue subscriptionQueue = session.createQueue("VirtualTopic.Orders::Consumer.A");
|
||
|
|
session.createConsumer(subscriptionQueue);
|
||
|
|
```
|
||
|
|
|
||
|
|
Durable topic subscribers in a network of brokers
|
||
|
|
-------------------------------------------------
|
||
|
|
The store and forward network bridges in 5.x create a durable subscriber per destination. As demand migrates across a
|
||
|
|
network, duplicate durable subs get created on each node in the network but they do not migrate. The end result can
|
||
|
|
result in duplicate message storage and ultimately duplicate delivery, which is not good.
|
||
|
|
When durable subscribers map to virtual topic subscriber queues, the queues can migrate and the problem can be avoided.
|
||
|
|
|
||
|
|
In Artemis, because a durable sub is modeled as a queue, this problem does not arise.
|