Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #9991

Re: JMS scalability question

Show all headers | View raw

sax...@gmx.de wrote:

Please attribute citations.

> Lew wrote:
>> Yes, it is.  One wonders why you would expect ten consumers to be faster with ten queues than with one?  And what about data integrity?
> 
> The idea is that there is a queue dedicated to each consumer. So the
> consumers knows that every message in the queue is for its own
> consumption. With a single queue every consumer needs to peek a
> message from the queue, check whether it is for itself, and if so also
> take it from the queue.

OK, I pictured fungible consumers, where each performs the same function with received messages so there's no need for peek-and-reject.

You're talking about consumers with different purposes, receiving different messages.  One might wish separate queues for that for functional reasons, never mind fantasies about optimization.

The performance impact of peek-and-decide before pulling a message will be negligible, I venture to say unnoticeable in the noise of system load.  Of course, neither of us knows without performance testing and profiling, but /a priori/ one can predict that the time to look at the current queue message and decide if it's for a particular consumer will be far, far less than the transport and delivery latency.  Let us know what your actual measurements tell you, and what the test conditions are.  Server load will influence results!
 
>> In some scenarios, e.g., display-processing events for a GUI, element order matters.  How would you coordinate element order in ten parallel queues?
> 
> Actually, I always thought that message order is not retained in JMS
> since it is an asynchronous system anyway. In my setting recipients

Oops.  Quite so.

> are supposed to establish the right message order themselves anyway
> since communication is asnychronous. It's about distributed actors
> communicating through process boundaries using JMS.
> 
>> One more consideration, based on many JMS-based systems I've seen in the wild: queues may be a very, very bad implementation for what you aim to accomplish.  What alternative architectures have you considered, and why were they inferior?
> 
> Oops. I'm surprised you think so. JMS is just made for asynchronous

"Think" so?  I observed so.

> message passing, no? I have thought of other systems like JavaSpaces,

Yes, and when people layer a synchronous messaging system between components on the same physical node in the same application archive over a JMS queue, one might discover that this is a suboptimal architecture.
> Terracotta, Hazelcast, JBoss Infinispan. But those systems are not
> only just about message passing, they provide a whole distributed
> programming system which goes beyond what I need. Except for
> Infinispan once you are looking for a clustered solution it gets
> really expensive. And I'm not sure storing some message for example in
> Infinispan, which triggers some event notification that upon receipt
> triggers some consumer to take this message from the Infinispan
> central space, is a good approach. At least a lot more complicated
> than with straight queues as in JMS.

This is why I asked about your use case.  Not all use cases call for queues, otherwise every single program would always use them.  No?

You aren't specific, given that you've only mentioned the solutions you've examined and not the purpose they should serve, but the shape of your search (assuming your analysis of what you need is correct) does indicate that your use case might be appropriate for queues.

In the wild, that is often not the case.  On a project where I worked a while back, I replaced a very complex queue-based submodule with a direct method call from the component formerly on one of the queue to a component formerly on the other end, and life got much better.

Not every JMS queue I've seen has been the wrong idea, but many have.

One downside to JMS queues is the deployment, configuration and management overhead.  The benefits have to justify the costs.

-- 
Lew

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

JMS scalability question saxo123@gmx.de - 2011-11-15 02:07 -0800
  Re: JMS scalability question Roedy Green <see_website@mindprod.com.invalid> - 2011-11-16 06:21 -0800
    Re: JMS scalability question saxo123@gmx.de - 2011-11-16 09:35 -0800
      Re: JMS scalability question Lew <lewbloch@gmail.com> - 2011-11-16 10:30 -0800
        Re: JMS scalability question saxo123@gmx.de - 2011-11-16 14:25 -0800
          Re: JMS scalability question Lew <lewbloch@gmail.com> - 2011-11-16 17:18 -0800
            Re: JMS scalability question saxo123@gmx.de - 2011-11-16 22:59 -0800
              Re: JMS scalability question jlp <jlp@jlp.com> - 2011-11-17 08:41 +0100
                Re: JMS scalability question saxo123@gmx.de - 2011-11-17 01:00 -0800
      Re: JMS scalability question Roedy Green <see_website@mindprod.com.invalid> - 2011-11-16 16:16 -0800
  Re: JMS scalability question Fredrik Jonson <fredrik@jonson.org> - 2011-11-17 08:11 +0000
    Re: JMS scalability question saxo123@gmx.de - 2011-11-17 01:26 -0800
      Re: JMS scalability question Fredrik Jonson <fredrik@jonson.org> - 2011-11-17 21:01 +0000
        Re: JMS scalability question Saxo <saxo123@gmx.de> - 2011-11-17 23:27 -0800

csiph-web