Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-users@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of sridharkomandur@gmail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=hcJVZgdTxjd2qmvLictdXoVQMsPaglWnPVfkDOGwbaX2/0xQTglnuqFWcgGoHPeKSgtBGjQKL5pnMbJM8OGDg1HpANGnfZqwA88GTHoZ6UVqOJjGeareKgdZP8aO/OPm++poj4o8caFupJiQRiQdLgkle8lZEcjP13q4PTbc6ok=
Message-ID: <ae7ffdb0607211417r75268f25r933f51a346343c45@mail.gmail.com>
Date: Fri, 21 Jul 2006 14:17:31 -0700
From: "Sridhar Komandur" <anon2005@komandur.com>
Sender: sridharkomandur@gmail.com
To: activemq-users@geronimo.apache.org
Subject: Re: Virtual Topics (was Re: Failover topic subscribers)
In-Reply-To: <ec6e67fd0607140237l2282c686re09d26c874b15d2f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_116648_7655045.1153516651169"
References: <ec6e67fd0607140237l2282c686re09d26c874b15d2f@mail.gmail.com>

------=_Part_116648_7655045.1153516651169
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

Thanks for the Virtual Topic feature.

We have a need for this feature now. Any ETA on this feature ?
Please let me know, if I can contribute in anyway to expedite the work.

Thanks
Regards
- Sridhar Komandur


On 7/14/06, James Strachan <james.strachan@gmail.com> wrote:
>
> I thought I'd change the subject as really we are discussing a kind of
> Virtual Topics where folks can use Queues to subscribe and consume
> from them etc...
>
>
> On 7/13/06, bmadigan <bmadigan@orbitz.com> wrote:
> >
> > This is almost working,
>
> YAY!
>
> > there are a few things I need to fix:
> > - Need to figure out how to add the new Broker to the factory without
> using
> > the plugin loader
>
> I was thinking, we should maybe add the Virtual Topic interceptor to
> the broker by default, but allow the configuration to be overridden in
> the activemq.xml as I can't help think it's be great to be able to use
> it out of the box.
>
> We've already got the "ActiveMQ.Advisory." prefix in topics to be used
> for advisories. So how about we use ActiveMQ.Virtual. as the prefix
> for the default prefix for virtual topics & we let folks customize
> this if they don't like the defaults?
>
> So we should maybe add a VirtualDestinationPlugin property on the
> BrokerService which is created by default (unless explicitly disabled
> using a bean property) which would auto-default to a sensible default
> that could be overloaded- or forks could set the virtual destinations
> to something else if they prefer etc.
>
>
> > - It may not be a problem, but I'm synchronizing  on next when I create
> the
> > queues for the virtual groups in addConsumer().  This could be finer
> grained
> > I think.
>
> Am not sure if you need to do that; I think the default mechanism of
> clients consuming on the queue with the destination auto-created on
> the fly would be fine?
>
>
> > - 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)
>
>
> > - 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 created a BrokerFilter subclass which overrides addConsumer() and
> send():
> >
> >  public Subscription addConsumer(ConnectionContext cc,
> >                                     ConsumerInfo ci) throws Exception {
> >         synchronized(next){
> >             String name  = ci.getDestination().getPhysicalName();
> >             if(name.startsWith(VIRTUAL)){
> >                 Set destinations = getDestinations(
> >                         new ActiveMQQueue(name));
> >                 if(destinations.size()==0){//create a new virtual queue
> >                     ActiveMQQueue queue = new ActiveMQQueue(
> >                             name+"?consumer.exclusive=true");
> >                         next.addDestination(cc,queue);
> >                     ci.setDestination(queue);
> >                 }else{ //queue exists, add the consumer
> >                     ActiveMQQueue queue = (ActiveMQQueue)
> >                             destinations.iterator().next();
> >                     ci.setDestination(queue);
> >                 }
> >             }
> >         }
> >         return next.addConsumer(cc, ci);
> >     }
> >
> >     public void send(ConnectionContext ctx,
> >                      Message message) throws Exception {
> >         String topic = message.getDestination().getPhysicalName();
> >         Iterator destinations = getDestinations(
> >                 new ActiveMQQueue(VIRTUAL + ".*." + topic)).iterator();
> >         while(destinations.hasNext()){
> >             Destination dest = (Destination) destinations.next();
> >             dest.send(ctx, message);
> >         }
> >         next.send(ctx, message);
> >     }
> >
> > Except for the subscription recovery part, this seems to work.
>
> Looks great - though am thinking we only really need the send() part -
> as the other stuff like adding consumers should just work out side the
> box (unless I'm missing something).
>
> BTW do you want to submit a patch, then we can start wiring this stuff
> in? Great work though - am excited to see this stuff implemented! :)
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>

------=_Part_116648_7655045.1153516651169--