Thanks much for the explanations. I've tried to backtrack the exploration process I went through to recreate the stack trace without success. I can tell you it was in the process of trying to create a Topic in the code to subscribe to from a virtualQueue. Sorry I can't be more specific.
James.Strachan wrote: > > 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/ > > -- View this message in context: http://www.nabble.com/Dynamic-Queue-Creation-tf3710227s2354.html#a10379763 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
