1

I think I understand the idea behind MOM or Message Queues, but I am not sure on the following implementation detail.
Since there is one element that acts as a dispatcher, it must have persistent TCP connections (since reliability is a requirement) to all of the clients.
So for N clients we have always open N (N being arbitrarily high) connections even if there is currently no communication.
Is this correct?
How is this handled by robust implementations of popular frameworks?

Beryllium
  • 12,808
  • 10
  • 56
  • 86
Jim
  • 18,826
  • 34
  • 135
  • 254

2 Answers2

2

If you have n clients, you have n connections.

And there might be others as well: if you have looked up the queue/connection factory etc. using JNDI, there is another connection to a JNDI port and the RMI registry (observed using JBoss 6).

On the other hand, if the messaging server uses select() on the TCP sockets, that's pretty efficient to handle a large number of connections using one thread only. As for the number of connections/sockets, have a look at this question: How many socket connections are possible.

I am not aware of a JMS implementation which uses UDP (including reliability). So you cannot really address it, since JMS uses TCP features for reliable and "in order" packety delivery.

  • If latency is not an issue, clients can always "connect, read, disconnect" every minute, for example.

  • As for ActiveMQ, it offers UDP transport, see here. In this case it's up to you to handle reliability.

  • If you have concerns regarding the number of connections/clients, you could consider "raw UDP" with an own protocol as an alternative.

Related: When to choose JMS API over UDP

Community
  • 1
  • 1
Beryllium
  • 12,808
  • 10
  • 56
  • 86
  • +1 interesting.`if the messaging server uses select() on the TCP sockets, that's pretty efficient`. I don't understand this point.This (the `select` is related to the resources of the server not the number of connections).So why are you mentioning this? – Jim Jul 31 '13 at 17:56
  • I've added it, just in case you worry about the server's performance, if it has to handle a large number of connections (in terms of CPU time, number of threads). If you just worry about the number of open sockets, I've updated the answer. Thus: before you look at alternatives, you could just test, if JMS is fast enough, even with a large number of connections. – Beryllium Jul 31 '13 at 18:29
1

Assuming the client wants to receive messages in real-time, then yes, an active and sustained connection to the JMS server is required.

Stand-alone JMS clients use dedicated connections, so 1 client=1 connection. Message-driven beans, on the other hand, which run inside an app server, reuse connection and session objects from a pool which is typically configurable in the app server to limit the number of those objects, nevertheless, the connections are "constantly" connected to the JMS server; the implementation of how that's done in the app server differs from product to product. So in an app server, if you have 20 MDB's consuming messages, but configure the pool to use 10 connections max, you can be sure only 10 connections will be opened.

Inactive Connection
A queue client does not have to be connected to the server, but messages will accumulate on the queue and, when the client connects, all messages will be delivered sequentially.

Connection Dropped
If the connection is dropped, the client (or container; not JMS server) must reconnect before consuming messages again.

Are you concerned about the number of connections to the JMS server? Are you referring to stand-alone JMS client, or MDB's?

raffian
  • 31,267
  • 26
  • 103
  • 174
  • May be I am missing some back-ground and I can not follow your answer.`the app server typically uses a pool of JMS connections for efficiency and to minimize connections` You mean that typically the client connect to the app server, and the app server connects to the message queue dispatcher?Otherwise I can not understand how connection could be reused? Additionally is this design the same in all implementations? E.g. ActiveMQ, RabbitMQ, etc? – Jim Jul 31 '13 at 05:45
  • I am mainly asking about standalone JMS clients. So `X` clients means `X` connections and as the clients go up the connections go up. How is this typically addressed. I assume that the increasing number of clients i.e. number of connections must be addressed somehow right? – Jim Jul 31 '13 at 16:34