On 7/14/06, bmadigan <[EMAIL PROTECTED]> wrote:
>> - I'm calling ConsumerInfo.setDestination(virtualQueue) to point the >> consumer to a virtual queue. This is probably incorrect, not sure if >> there >> is a better way. > > Are you trying to transform a durable topic consumer into a queue > consumer? Am not sure you need. Am thinking if you are a topic > consumer (durable or non-durable) then we leave you as you are; a > fully JMS compliant durable topic consumer. However to use the nice > queue-centric virtual topics, you really use a queue consumer of the > right name and things all just work. (BTW the topic regions are > optimised so that if no consumers are available, publishing to a topic > is a no-op) > Yep, thats what I was attempting. If a subscriber signs up to a virtual topic, a queue is created for the virtual topic group. I was synching on next to make sure only one queue is created for any group of consumers. If I can just have the consumer subscribe to a Queue called ActiveMQ.Virtual.GroupName.TopicName, then I can just get rid of the addConsumer implementation completely. That makes it even simpler!
Agreed! Then it means that we're reusing all that code for auto-creation of queues etc.
>> - The virtual queues can't provide subscription recovery. Not sure how to >> handle that. > > Yeah thats true. Am not too worried about that right now - but we > could look at fixing that later on. > I think it will work now that I am not creating the Queues in the interceptor. I will test this since most of our teams implementing listeners require recovery.
OK. BTW note that once a queue is created, messages will be delivered to it for the virtual topic; so we'll have to add some kind of message eviction for non-persistent messages at some point. (A quick fix could be to make them persistent by default :) -- James ------- http://radio.weblogs.com/0112098/
