Generally speaking I would avoid use-cases involving a JMS queue + selectors when possible for the following reasons:
- The queue has to be scanned over and over for messages which match the selectors. The deeper the queue gets the more scanning is required. This adds up over time. - A single queue with X traffic will almost certainly not be as fast as Y queues with X/Y traffic on each. Put simplistically, more concurrency equals more performance both in terms of throughput and scalability. Justin On Tue, Dec 20, 2022 at 5:26 PM John Lilley <john.lil...@redpointglobal.com.invalid> wrote: > Greetings! > > > > We have a design wherein every “job” that runs offers up an RPC service > via a unique queue name. Which means that if 100 jobs are running, there > are 100 queues. I’ve read that, in theory, all jobs could share a single > queue and use Message Selectors (in JMS) to receive only messages that they > should service. Can anyone help me understand the tradeoffs? Would shared > queue tend to use less broker memory? Would the shared queue performance > start to degrade under load? > > > > Thanks, > > John > > > > [image: rg] <https://www.redpointglobal.com/> > > John Lilley > > Data Management Chief Architect, Redpoint Global Inc. > > 888 Worcester Street, Suite 200 Wellesley, MA 02482 > > *M: *+1 7209385761 <+1%207209385761> | john.lil...@redpointglobal.com > > PLEASE NOTE: This e-mail from Redpoint Global Inc. (“Redpoint”) is > confidential and is intended solely for the use of the individual(s) to > whom it is addressed. If you believe you received this e-mail in error, > please notify the sender immediately, delete the e-mail from your computer > and do not copy, print or disclose it to anyone else. If you properly > received this e-mail as a customer, partner or vendor of Redpoint, you > should maintain its contents in confidence subject to the terms and > conditions of your agreement(s) with Redpoint. >
