Re: JMS scalability question
Please attribute citations.
Yes, it is. One wonders why you would expect ten consumers to be fast=
er 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 wi=
th 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 messa=
ge 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 measureme=
nts tell you, and what the test conditions are. Server load will influence=
In some scenarios, e.g., display-processing events for a GUI, element or=
der matters. How would you coordinate element order in ten parallel queu=
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 ac=
complish. What alternative architectures have you considered, and why we=
re 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 component=
s on the same physical node in the same application archive over a JMS queu=
e, 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 searc=
h (assuming your analysis of what you need is correct) does indicate that y=
our use case might be appropriate for queues.
In the wild, that is often not the case. On a project where I worked a whi=
le back, I replaced a very complex queue-based submodule with a direct meth=
od call from the component formerly on one of the queue to a component form=
erly 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.