我想我理解MOM或Message Queues背后的想法，但我不确定以下实施细节。
由于有一个元素充当调度程序，因此它必须具有持久的TCP连接（因为可靠性是必需的）到所有的客户端。
因此，对于N个客户，即使当前没有通信，我们也始终打开N（N为任意高）连接。
这是对的吗？
这是如何通过流行框架的强大实现来处理的？
答案 0 :(得分：2)
如果您有 n 个客户，则 n 连接。
也可能有其他人：如果您使用JNDI查找了队列/连接工厂等，则还有另一个连接到JNDI端口和RMI注册表（使用JBoss 6观察）。
另一方面，如果消息传递服务器在TCP套接字上使用select()，那么仅使用一个线程处理大量连接就非常有效。至于连接/套接字的数量，请看一下这个问题：How many socket connections are possible。
我不知道使用UDP（包括可靠性）的JMS实现。所以 你无法真正解决它，因为JMS使用TCP功能来实现可靠和“有序”的包装交付。
如果延迟不是问题，例如，客户端每分钟都可以“连接，读取，断开连接”。
对于ActiveMQ，它提供UDP传输，请参阅here。在这种情况下，由您来处理可靠性。
如果您对连接/客户端数量有疑虑，可以考虑使用自己的协议“raw UDP”作为替代方案。
答案 1 :(得分：1)
假设客户端希望实时接收消息，则是，需要与JMS服务器建立活动且持续的连接。
独立JMS客户端使用专用连接，因此1个客户端= 1个连接。另一方面，消息驱动的bean在app服务器内运行，重用来自池的连接和会话对象，通常可在app服务器中配置以限制这些对象的数量，然而，连接“不断”连接到JMS服务器;在app服务器中完成的方式的实现因产品而异。因此，在应用服务器中，如果您有20个MDB消费消息，但配置池最多使用10个连接，则可以确保只打开10个连接。
无效连接
队列客户端不必连接到服务器，但消息将累积在队列中，当客户端连接时，所有消息将按顺序传递。
连接丢失
如果连接断开，客户端（或容器;而不是JMS服务器）必须重新连接，然后再次使用消息。
您是否关注与JMS服务器的连接数？ 您指的是独立的JMS客户端，还是MDB的？