Could a JMS message queue have multiple consumers simultaneously? If can, how to implement that? My experiences showed that at any time there is only one consumer allowed for a JMS message queue. If a subsequent consumer tried to attach to the same queue, the following exception would be thrown out: ===================================================== [b]javax.jms.ResourceAllocationException: [C4073]: A JMS destination limit was reached. Too many Subscribers/Receivers for Queue : PhysicalQueue user=guest, broker=CTPLIT015PC:7676(1462)[/b]====================================================== On the contrary, definitely multiple consumers can be attached to the same Topic.
- Posted by: Daniel X
- Posted on: May 19 2006 05:16 EDT
- Re: Can a JMS queue be attached by multiple consumers simultaneo by Viliam Durina on May 22 2006 04:05 EDT
- Re: Can a JMS queue be attached by multiple consumers simultaneously by James Strachan on May 22 2006 07:53 EDT
- How to increase the limitations of the JMS provider? by Daniel X on May 29 2006 05:25 EDT
Conceptually can and we are using it with Oracle Advanced Queuing. Maybe it is limitation or setting of your JMS provider, that only one consumer can dequeue.
Could a JMS message queue have multiple consumers simultaneously? If can, how to implement that?Absolutely! Most decent JMS providers should support load balancing of requests on a queue across multiple consumers. Its one of the main point of using Queues to get load balancing :) If your provider limits the number of consumers per queue consider using another provider. Incidentally one thing to be careful of is ordering; using multiple consumers per queue typically breaks ordering. Though you can use Message Groups to fix this; getting parallel processing of messages while preserving ordering across a correlation ID. James LogicBlaze Fuse: the Open Source SOA runtime
Thus how can I increase the limitations of the JMP provider to tolerate multiple concurrent consumers? What I am using is SUN application server's Admon Console.