activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Virtual Destination changes
Date Thu, 27 Jul 2006 15:35:21 GMT
BTW I've just updated the documentation to show how to customize the
virtual topic behaviour via XML

http://activemq.org/site/virtual-destinations.html

There is also an example of a Composite Queue where sending a message
to a queue/topic can really result in the message being forwarded to a
number of actual physical destinations.


On 7/27/06, James Strachan <james.strachan@gmail.com> wrote:
> I've made a few changes to the virtual destinations feature...
> http://activemq.org/site/virtual-destinations.html
>
> 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
> added.
>
> 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
> code)...
>
> 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
> Consumer.$subscriberName.VirtualTopic.>
>
> 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
> Consumer.B.VirtualTopic.Cheese).
>
>
> 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
>
> <broker>
>   <virtualDestinations>
>       <virtualTopic name=">"/>
>     </virtualDestinations>
>
> or you could create custom virtualTopic wildcards if you wish etc.
>
> Does this seem OK to folks?
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>


-- 

James
-------
http://radio.weblogs.com/0112098/

Mime
View raw message