One JMS Queue with Multiple Consumer

Question

I have an Oracle Commerce Application which is consuming Messages over one JMS Queue. I have Ten Consumers all with same destination Queue. I would like to understand Pros and Cons of this architecture and how to optimize this.

Answer 1

I just want to state that this question has no specific bearing on Oracle Commerce and is about general principles of implementing queues.

When you've one queue and many consumers, remember that they will all try to process the messages simultaneously. This may not be desirable for some situations if order of processing messages are important or there are dependent messages that need to be processed before processing the current message. Even with this, there are patterns that can put messages back to the queue for processing later to achieve dependent message processing.

Exception handling is another tricky subject when you've multiple consumers. Ensure that the whole message handling has good exception handling and deposits the message back to the queue (by way of throwing exceptions) for processing later. Also, if there is a message that could get stuck processing because it will generate every time you may want to put them in different queue, after so many exceptions. At one time, we built an Exception Handling Framework that helped with all these scenarios.

If you really want to just broadcast the message to many consumers on a topic, use pub-sub architecture and that is much easier to handle.

Again, like the other comment said the scenario of what you're trying to do will help providing good direction.

Here is a discussion that could additionally help with your question - http://c2.com/cgi/wiki?MessageQueuingArchitectures

Answer 2

when the consumers share the workload it is common that they share a queue. otherwise it could be better to create a separate queue for every consumer.

if you would like to broadcast bij putting a message on a tippic than there is a possibility to create a bridge for every consumer.

by this i mean a bridge from a toppic to the consumer queue. the pro's for using the bridge is that te messages wil stay in the queue (als long als the message doesn't expire ) when the consumer process is down for a short period.