On 5/8/07, SBenj <[EMAIL PROTECTED]> 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
supported.
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
queue).
--
James
-------
http://macstrac.blogspot.com/
