This question applies to MQSeries as well. If you have 100 use cases to be sent asynch through JMS, is it better to have 100 queues that only handle those use cases, or 1 queue and have the MDB forward each message on based on information in the envelope? Opinions? Thanks
I am not a hard-core messaging guy, but in general I think many small queues are better than a few big ones. With a few big queues, you have to sort messages by message properties, which is not as straightforward or performant.
I agree with that from a conceptual and maintenance standpoint, but I wonder how much overhead there is with adding a MQ or a JMS queue. From a design standpoint, it makes much more sense to have a queue for each use case.
From what I have read about MQSeries, the performance impact of lots of little queues is pretty minimal, or even has better performance than a few big queues.
The definitive answer is: it depends :-)
Really it depends on how many messages you see pumping through the system, what your performance requirements are, and your hardware environment. In a high performance environment you typically want to use multiple queues, because JMS implementations are optimized along queue/topic lines. They're how you can most effectively partition trafic - and distributing information in that manner is where a large portion of the work in a JMS implementation goes.
If you have a light message traffic, and expect it to stay that way, then it probably doesn't matter and many queues may just introduce unneeded complexity.
And, of course, as always, if you're talking high performance do prototype testing of your JMS implementation to see if it handles your specific requirements and anticipated design well.