activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <gno...@gmail.com>
Subject Re: Virtual Destination changes
Date Thu, 27 Jul 2006 13:28:28 GMT
Sounds good.

Does virtual topics will fit ServiceMix requirement for WS-Notification
clustering ?
Currently, one problem is that if you deploy the same WS-Notification
consumer on several nodes, they will not act as a single consumer with load
balancing between the consumers.  It seems to be the exact need :)
I will raise a JIRA so we update the WS-Notification component to use
virtual topics, once we upgrade to AMQ 4.1.

Cheers,
Guillaume Nodet

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/
>



-- 
Cheers,
Guillaume Nodet

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message