activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Budworth" <dbudwo...@gmail.com>
Subject Re: Posting to a virtual topic's physical queue
Date Wed, 23 May 2007 17:52:34 GMT
For what it's worth (James' solutions are probably better)... if you need
'random' access to queues from jboss (or any JNDI enforced thing), you can
create your own JNDI context (javax.naming.Context) and bind that to some
spot in the jboss jndi tree, then all you do is override Context.lookup(name)
to return a new Queue('name')

example, in our case, our queues are in the form of 'work.queue.[SOME QUEUE
NAME]'
and we bind out context object to /jms/auto/queue

then in the MDBs (ejb3 MDB) we just set the queue jndi name to
"/jms/auto/queue/work.queue.blah"

keeps us from having to define the queue in some kind of jndi binding tree
in addition to the (required) MDB setting.

Like I said, James' solution is probably better, but if you are stuck using
MDBs, there's really no alternative since the spec requires JNDI bindings
for the destination.


On 5/23/07, James Strachan <james.strachan@gmail.com> wrote:
>
> On 5/23/07, sbuberl <sbuberl@gmail.com> wrote:
> >
> >
> >
> > James.Strachan wrote:
> > >
> > > On 5/23/07, sbuberl <sbuberl@gmail.com> wrote:
> > >>
> > >> Hi.
> > >>
> > >> My server posts live highway traffic accidents and events to topics,
> but
> > >> most messages are only updates on existing event data. So I set up my
> > >> server
> > >> to monitor when a client logs in/out and sends them all live events
> in
> > >> one
> > >> message. I can't use durable subscriptions on topics because that
> would
> > >> send
> > >> them lots of old data as well when my subscribers only want the live
> > >> data.
> > >>
> > >> I successfull intergrated activeMQ with JBoss and I have beans
> monitoring
> > >> when a client logs in/out and when they create a consumer on the
> event
> > >> topic
> > >> with my database.  All updates get sent to the following virtual
> topic:
> > >> <virtualTopic name="ATIS" prefix="Consumers.*." />
> > >>
> > >> The problem is: how can I retrieve the queue to send to with JBoss?
> > >
> > > Given your requirements, you probably don't want to use a queue per
> > > client as you only want live messages being sent. Virtual topics &
> > > queues work like durable topic subscribers.
> > >
> > > I'd recommend just using a Topic with non-persistent delivery of the
> > > messages
> > >
> > > --
> > > James
> > > -------
> > > http://macstrac.blogspot.com/
> > >
> > >
> >
> > Thanks for the advice on switching off virtual topics.  I was fine with
> one
> > topic before, but I switched to virtual topics and queues because I
> still
> > need to have each client have its own queue/topic in order to send a
> logging
> > in client a "refresh" message (as stated before, a single message of all
> > live events in one message).
>
> There's a cooler solution. You can send individual initial messages to
> consumers via topics using the subscription recovery policy and a
> custom initial message query...
> http://activemq.apache.org/subscription-recovery-policy.html
>
> basically as a topic subscription starts you have the option to send
> one or more intiial messages. You just use this
>
>
> http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/broker/region/policy/QueryBasedSubscriptionRecoveryPolicy.html
>
> and then provide your own implementation of
>
>
> http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/broker/region/policy/MessageQuery.html
>
> which can just create the initial refresh message(s).
>
> i.e. you could support some kinda 'last image caching' type thing
> where the consumer receives the last stable state first before any
> future updates
>
>
> > So if I switch to regular topics, I'm still
> > stuck in the same boat of binding each client topic to JBoss JNDI?
>
> There's only 1 topic for all clients; so 1 JNDI entry (if you use JNDI
> - personally I try and avoid it at all costs & use Spring or Java code
> instead :)
>
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>

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