Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!novia!news-out.readnews.com!news-xxxfer.readnews.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: JMS scalability question Date: Wed, 16 Nov 2011 10:30:27 -0800 (PST) Organization: http://groups.google.com Lines: 55 Message-ID: <5890740.1493.1321468227592.JavaMail.geo-discussion-forums@prap37> References: <5f805cc6-58b1-49e5-933f-4c6dbbceb65d@g7g2000vbd.googlegroups.com> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 2620:0:1000:2404:224:d7ff:fe69:5838 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1321468675 10013 127.0.0.1 (16 Nov 2011 18:37:55 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 16 Nov 2011 18:37:55 +0000 (UTC) In-Reply-To: <5f805cc6-58b1-49e5-933f-4c6dbbceb65d@g7g2000vbd.googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2620:0:1000:2404:224:d7ff:fe69:5838; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:9981 sax...@gmx.de wrote: > thanks for your reply. I see what you mean. You would mostly play with > control valves that are outside the software like adding servers or > adding RAM. >=20 > Let's say there are 10 consumers and everyone takes messages from a > queue exclusively assigned to itself. Consequently, there are 10 > queues in total. Now, each queue is filled with 100 messages each. I > would expect these 1000 messages in total to be processed faster this > way than, say, 1000 messages sitting in a single queue served by a > single consumer. Naively speaking, those 10 consumers should eat up > those 1000 messages 10 times faster. But this is pure mind gambling. Yes, it is. One wonders why you would expect ten consumers to be faster wi= th ten queues than with one? And what about data integrity? In some scenarios, e.g., display-processing events for a GUI, element order= matters. How would you coordinate element order in ten parallel queues? Ten consumers sipping off a single queue can be blazingly fast, if they gra= b from a concurrent queue and hare off in their own threads to process the = data. You still might face the event-order problem, of course. > No clue how things would turn out in reality. Maybe the increased > network traffic of 10 consumers polling a queue instead of a single > one would decrease performance... Maybe, but there's no particular reason to think so, or that if it exists s= uch a penalty would be measurable. > Do you think it would be useful to make the "message bus" pluggable in > the sense that some SPI is provided so that anyone can increase the > number of queues if considered appropriate? I wonder whether that kind > of pluggable message bus system already exists. Guess it does since > there must be a need for something like this. One more consideration, based on many JMS-based systems I've seen in the wi= ld: queues may be a very, very bad implementation for what you aim to accom= plish. What alternative architectures have you considered, and why were th= ey inferior? All your talk of what's faster this, and what's maybe slower than that, is = wasted mental energy right now. You don't even evince a basic architecture= in your posts, which architecture must perforce conform to the logical pro= blem you aim to solve. Details of what number of them > 1, are so prematur= e at this point. First figure out even whether to use queues at all! Also based on my experience, you really never need more than one JMS queue = in each direction between communicating components. Less than one, surely,= but I can't recall needing more than one except in very, very rare, high v= olume circumstances. We're talking millions of messages per hour per queue= , not a piddling ten, before this becomes an issue. --=20 Lew