> Now, what is better (faster) in performance?
> 1. Have one queue that all writers write to, and the readers specify a
> filter in the consumer to read only the relevant messages.
> or
> 2. Have multiple queues, and the writer webservice figures out which
> queue to put the message at.
Well there is no simple answer [how many times have we heard it :)].If it is
merely selectors vs multiple destinations you could find your answer at
"Selectors" section at
http://developers.sun.com/sw/docs/articles/integration/tuning_tradeoffs.html
[This is a slightly dated document but should help you get started]
Use of multiple queues however assumes that you control all the producers and
the producers and consumers are always in sync with "messagetype to destination
mapping" etc.
Thanks
--Siva.
Daniel Cavalcanti wrote:
> Hi...
>
> I have a simple question that I've been thinking about but can't come up
> with the answer/choice.
> Here is the scenario. I have a system with a web service interface. A
> client sends a message, which I'll put in a JMS queue.
> I also have another web service interface that will retrieve messages
> from a JMS queue. Your tipical writer/reader.
>
> Depending on some parameters in this message, I'll place it in a
> "particular" queue. Basically, these parameters are used to seggregate
> messages to respective writers and readers.
> Now, what is better (faster) in performance?
> 1. Have one queue that all writers write to, and the readers specify a
> filter in the consumer to read only the relevant messages.
> or
> 2. Have multiple queues, and the writer webservice figures out which
> queue to put the message at.
http://developers.sun.com/sw/docs/articles/integration/tuning_tradeoffs.html
> If (2) is the best performance option, is there a way to make that queue
> mapping/routing simple? With option (1), the code is very simple, just
> specify the filter for the consumer.
> The one requirement is that I can't lose any messages... The system will
> be heavily loaded, so it needs to have a high throughput.
>
> thanks,
> Daniel.