You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by James Strachan <ja...@gmail.com> on 2006/07/27 15:15:31 UTC
Virtual Destination changes
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/
Re: Virtual Destination changes
Posted by James Strachan <ja...@gmail.com>.
On 7/27/06, bmadigan <bm...@orbitz.com> wrote:
> Looks good. So will producers need to publish to VirtualTopic.Cheese, or will
> publishing to Cheese still allow the interceptor to find the virtual Queues
> using the wildcard as in the initial implementation?
Out of the box it'll require VirtualTopic.Cheese but if you use the
activemq.xml example on this page you can use any topic you like...
http://activemq.org/site/virtual-destinations.html
i.e. the default wildcard for virtual topic features is
"VirtualTopic.>" but you can configure it to be ">" if you prefer so
that all topics become virtual
--
James
-------
http://radio.weblogs.com/0112098/
Re: Virtual Destination changes
Posted by bmadigan <bm...@orbitz.com>.
Looks good. So will producers need to publish to VirtualTopic.Cheese, or will
publishing to Cheese still allow the interceptor to find the virtual Queues
using the wildcard as in the initial implementation?
Thanks,
Brian M.
--
View this message in context: http://www.nabble.com/Virtual-Destination-changes-tf2009484.html#a5525283
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Virtual Destination changes
Posted by James Strachan <ja...@gmail.com>.
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 <ja...@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/
Re: Virtual Destination changes
Posted by James Strachan <ja...@gmail.com>.
On 7/27/06, Guillaume Nodet <gn...@gmail.com> wrote:
> 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 :)
Exactly! I'd not thought of that use case - my bad.
Basically JMS durable topics suck as they only allow 1 thread globally
to consume from a logical subscription - whereas with virtual topics
we can run many threads in many JVMs in a cluster consuming from the
virtual topic using a queue per logical subscription and so supporting
load balancing, failover and so forth.
> I will raise a JIRA so we update the WS-Notification component to use
> virtual topics, once we upgrade to AMQ 4.1.
Great!
I wonder could we also use Message Groups as well by default? Am
wondering if there's an easy way to partition the messages on the
topic to perform some kind of sticky load balancing. i.e. is there any
value of JMSXGroupID we could think of to set by default to increase
parallelisation but preserve ordering.
http://incubator.apache.org/activemq/message-groups.html
e.g. maybe the producer ID - then at least all messages would be
ordered for a single producer when using WS-Notification plus we'd
have load balancing and failover etc
--
James
-------
http://radio.weblogs.com/0112098/
Re: Virtual Destination changes
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ja...@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