activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Virtual Destination changes
Date Thu, 27 Jul 2006 13:15:31 GMT
I've made a few changes to the virtual destinations feature...

Firstly I wanted to have out of the box support for virtual topics;
however I was a little worried about adding the extra overhead of
virtual topic functionality to everyones installation of ActiveMQ,
particularly as some users have very high performance requirements.

So I refactored the virtual destination functionality to be a form of
DestinationInterceptor. That way the cost is only incurred when
sending to a destination which has a virtual destination capability

It also means we can add per-destination interceptors easily now (I"m
sure we could think of some other useful ones in the future).

I wanted to make virtual topics available as a default, but not impose
the cost of them (even though they are fairly cheap). Also I was
having reservations of my previous suggestion of using
ActiveMQ.Virtual.> as the prefix for consumers - as ActiveMQ.> is
typically the internal administration namespace.

So I'm thinking of the following out of the box (you can of course
configure this explicitly to do whatever you need via XML or Java

Topics matching VirtualTopic.> get the virtual topic capability -
other topics do not. (So zero overhead added).

To consume from the virtual topic via a queue you subscribe to

e.g. you could publsh to topic VirtualTopic.Cheese and subscribe to
Consumer.A.VirtualTopic.Cheese using the default to get virtual
topics. (Or for another virtual topic consumer just subscribe to

To enable virtual topics on any topic (incurring a small cost per
send) then you could configure something like this which effectively
matches all topics

      <virtualTopic name=">"/>

or you could create custom virtualTopic wildcards if you wish etc.

Does this seem OK to folks?


View raw message