Queues - 1 MDB or many?

Question

I need an opinion - how well would a system with a single MDB that handles multiple message types (e.g. xml messages, with tags to indicate the type of message) vs having multiple MDB's per topic. I guess I'm looking at a "best practice" pattern. I've been thinking of this and realized that if you have a single MDB with multiple message types, then this could mean that if there were a message type that sees a high volume vs another that sees a lower volume, the lower volume message processing of the messages would be delayed.
From what I've read, the container is supposed to compensate for a high volume of messages through creating more instances, but this still doesn't stop the fact that the messages are processed FIFO, so having multiple topics would be a far more better way to go.
The hope here however was to have a model where we would only have two types of messages initially processed asynchronously, while the others were processed synchronously through regular session beans, but additional message types may be turned on later to run asynchronously without having to create new MDB's for each additional topic. But I think this could just mean creating unnecessary delays for other types of messages.
(reposted from AQ forum...figured this may be a better forum for this)
Any thoughts?
Thanks

Answer 1

Jason -- One important point is that the EJB specification (specifically MDBs) does not guarantee FIFO processing. Here is the quote from section 15.4.6 of the spec:
A container allows many instances of a message-driven bean class to be executing concurrently, thus allowing for the concurrent processing of a stream of messages. No guarantees are made as to the exact order in which messages are delivered to the instances of the message-driven bean class, although the container should attempt to deliver messages in order when it does not impair the concurrency of message processing. Message-driven beans should therefore be prepared to handle messages that are out of sequence: for example, the message to cancel a reservation may be delivered before the message to make the reservation.
That said, I have seen queuing systems that have used both types of arrangements you describe (although none were using JMS.) For the generic case, there were problems if the queue was backed up so you might consider multiple queues with different priorities, each of which has a generic payload. This helps starvation of time critical messages.
If you do establish different topics, then you will have more work to do in terms of deployment and management of the topics, but the messages will be cleanly separated and you may be able to make some optimizaitons of message processing since they can be created in a form that best mathces their use.
Overall, my experiences with generic queues, once we established multiple queues with different priorities, was good. Just be ready for the additional overhead of processing XML messages.
Thanks -- Jeff