activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Dynamic Queue Creation
Date Tue, 08 May 2007 16:16:11 GMT
On 5/8/07, SBenj <> wrote:
> (MQ 4.1, Java 1.6, Redhat)
> I have a question regarding Queues and Topics as their use relates to our
> business case. We have a few hundred clients, each of whom will need to
> subscribe to their own "mailbox". New clients are continually created every
> few days (they're remote business sites) and generally don't go away,
> although the sites may go offline now and again. Messges come in in a
> continuous stream for the clients, often before the client itself becomes
> live.
> We'd like to bring up each clients mailbox when a message comes in for them,
> or when the site comes live and requests messages. It seems like there are a
> number of ways to model this with MQ, each of which seems to be problematic:
> 1. Durable Subscribers - each site becomes a subscriber to it's own topic.
> This works fine, except that the topic will not hold any messages before the
> client goes live for the first time and registers itself as a durable
> subscriber.
> 2. Queues - Message comes in for an unknown client, we create a queue for it
> on the fly. This seems to work. However (quoting from the sun j2ee javadoc
> for session.createQueue:
> createQueue
>    " This facility is provided for the rare cases where clients need to
> dynamically manipulate queue identity. It allows the creation of a queue
> identity with a provider-specific name. Clients that depend on this ability
> are not portable.
>     Note that this method is not for creating the physical queue. The
> physical creation of queues is an administrative task and is not to be
> initiated by the JMS API. The one exception is the creation of temporary
> queues, which is accomplished with the createTemporaryQueue method. "
> Any ideas on why this is a concern?

It might not work on some providers - but on the good ones its fine :)

> 3. VirtualTopics - This seems to create class cast errors in ActiveMQ - i.e.
> when trying to create a durable subscriber for a virtual topic, activemq
> seems to be trying to cast to a queue.

Got a stack trace?

> 4. MessageSelectors - I suppose we could dump everything into a large queue
> and have a selector for each client, but this would require each message to
> be examined by hundreds of clients, worst case.

Not quite, the broker implements selectors so clients will only get
messages which match their selector

>  (2) seems to do exactly what we want, but there's that scary message from
> sun. Any help on the above would be most appreciated. Thanks.

If you are using ActiveMQ then you can ignore Sun's scary messages;
creating queues dynamically is lightweight, fast and totally

BTW for clients which come online, its typical to use temporary
queues; which can be easily created on startup and have the benefit of
being destroyed when the client goes offline. So it mostly depends on
what semantics you want; do you want to persist messages across client
disconnects (if so use a regular queue) or not (use a temporary


View raw message