JMS Receive 内部如何工作？
我一直在研究各种通信技术/架构/模式/实现（阅读：流行语），包括 Web 服务（WCF、Axis2）、ESB、SOA，并且想了解有关消息传递的 JMS 的更多信息。
从概念上讲，JMS 听起来很简单。我的看法是，它是一个中间代理，管理来自发布者的消息并将它们路由到适当的订阅者。这是通过在发布消息时对消息进行排队并在接收消息时将其出队来完成的。
问题 1：我对 JMS 的基本理解正确吗？
在阅读有关技术的内容时，令我烦恼的一件事是，当人们对某个功能进行某种程度（有意或无意）的挥手时。
根据我的基本理解，JMS Provider 必须运行才能发送或接收消息。我对发布的假设是，JMS 提供程序只是等待消息发布，然后将其存储在队列中（内存或数据库支持，具体取决于实现）。但是，我不太确定接收是如何工作的。
问题 2：如果没有可用消息，接收（通常）是否会阻塞？
问题 2b：如果是这样，如何实现阻塞？客户端是否持续轮询消息？服务器是否在消息发布之前根本不响应（如何在不超时的情况下工作？）提供者是否向接收者发起呼叫？
问题 2c：如果没有，如何确保消息被发布及时接收，而不影响性能？
基本描述似乎倾向于单个 JMS 提供者，以确保消息集中管理而不丢失。我可以看到缩放是一个问题。
问题 3：JMS 如何扩展？
在扩展时，我发现无论哪个物理服务器接收消息，确保将单个消息传递给所有适当的订阅者都非常复杂。
问题 3b：JMS 实现如何确保扩展环境中的可靠交付？
请注意，虽然这些问题与 JMS 相关，但它们可能适用于任何消息传递基础设施。我欢迎特定于 JMS 的答案以及更通用甚至特定于其他技术的答案。
I've been researching various communication technologies/architectures/patterns/implementations (read: buzzwords) including Web Services (WCF, Axis2), ESBs, SOA, and wanted to know more about JMS with regards to messaging.
Conceptually, JMS sounds simple. My take is that it's an intermediate broker which manages messages from publishers and routes them to appropriate subscribers. This is done by queueing messages as they are published, and dequeuing them as they are received.
Question 1: Is my basic understanding of JMS correct?
One of the things that bugs me when reading about technologies is when a certain level of (intentional or unintentional) hand-waving is done about a feature.
Based on my basic understanding, a JMS Provider must be running in order to send or receive messages. My assumption on publishing is that the JMS Provider simply waits until a message is published, then stores it in a queue (memory or database-backed, depending on implementation). However, I am not quite sure how receive works.
Question 2: Does receive (typically) block if no messages are avaiable?
Question 2b: If so, how is blocking achieved? Does the client continuously poll for messages? Does the server simply not respond until a message is published (how does this work without timing out?) Does the provider initiate a call to the recipient?
Question 2c: If not, how does one ensure messages are received in a timely manner, without impacting performance?
The basic description seems to lean towards a single JMS provider to ensure that messages are centrally managed not lost. I can see scaling being an issue.
Question 3: How does JMS scale?
When scaling, I can see there being complexities to ensure that a single message is delivered to all appropriate subscribers, regardless of which physical server receives the message.
Question 3b: How does a JMS implementation ensure reliable delivery in a scaled environment?
Please note that although these questions are related to JMS, they likely apply to any messaging infrastructure. I welcome answers specific to JMS as well as those which are more general or even specific to another technology.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我试图根据我在 JMS 上的经验回答几个问题。
答案1：- JMS是Java消息服务API；它为Java客户端访问消息传递框架提供统一的接口。 JMS API 之下是符合 JMS 的消息传递提供程序，例如 WebSphere MQ 提供程序。
JMS 支持通过任何消息传递协议将有效负载传输到目的地，即。队列和主题。
这些是 JMS 的基础知识。
接收工作如何进行？
JMS 规范提供了两个重要的类：
MessageConsumer和MessageListener。MessageConsumer类允许 JMS 客户端通过调用其任何receive()方法来同步接收 JMS 消息。此调用将阻塞线程，直到收到消息。否则，可以通过向
MessageConsumer注册MessageListener对象来进行异步接收。JMSProvider 知道消息已到达其本地目的地，其工作是将消息传递到轮询消息使用者线程或非轮询注册消息侦听器线程。
答案2：-
MessageConsumerAPI 有两种接收变体：receive()和receive(long timeout)。后一种变体让MessageConsumer线程阻塞，直到消息在特定超时期限内到达，否则超时。不同的消息传递框架可能以不同的方式实现阻塞功能。由于 JMS 对象是 JNDI 管理的对象，并且提供者特定的代理对象返回到 JMS 客户端，这意味着客户端不知道阻塞是如何在后台发生的。特定的消息传递框架可以在特定时间段之后选择消息消费者线程轮询。或者，它可以选择阻止，直到发送通知。
我不确定您是否正在寻找特定 JMS 兼容消息传递框架的答案？
答案3：-
我猜想，JMS 扩展意味着能够在多个物理机器上拥有多个发布者/订阅者、多个目的地。 JMS 扩展需要底层消息传递提供程序的支持，以支持某种集群/故障转移。因此，JMS 规范不支持可伸缩性。如果我错了请纠正我？例如，我曾开发过兼容 JMS 的 WebSphere MQ，它提供了集群支持。
I am trying to answer few questions based on my experience on JMS.
Answer 1:- JMS is Java Message Service API; it provides uniform interface for Java clients to access messaging framework. Beneath JMS API is a JMS compliant messaging provider, for example WebSphere MQ provider.
JMS supports transport of a payload over any messaging protocol to destinations viz. Queue and Topic.
These are basics of JMS.
How does receive work?
JMS specification provides two important classes:-
MessageConsumerandMessageListener.MessageConsumerclass allows a JMS client to synchronously receive JMS messages by calling any of itsreceive()method. This call will be blocking thread until a message is received.Otherwise, asynchronous receive can be made by registering an object of
MessageListenerwithMessageConsumer.It is JMSProvider who get to know that a message is arrived in its local destination and its job is to deliver messages to either polling message consumer thread or non-polling registered message listener thread.
Answer 2:-
MessageConsumerAPI has two variants of receive:receive()andreceive(long timeout). The latter variant letsMessageConsumerthread block until message arrives within specific timeout period or else it times out.Different messaging frameworks might implement blocking feature in different ways. As JMS objects are JNDI administered objects and provider specific proxy objects are returned to JMS client, it means that the client is unaware of how blocking is happening in background. A particular messaging framework may choose message consumer thread polling after a particular time period. Alternatively, it may choose to block until notification is sent.
I am not sure if you are looking answer for a particular JMS compliant messaging framework?
Answer 3:-
I guess by JMS scaling you mean ability to have many publishers/subscribers, many destinations over multiple physical machines. JMS scaling requires support of underlying messaging provider to support some sort of clustering/fail over. As such JMS specification does not support scalability. Correct me if I am wrong on this? For example I have worked on JMS compliant WebSphere MQ which provides clustering support.
让我们先弄清楚术语。您不能说
JMS Provider 必须正在运行，因为Provider 是构建JMS 服务器的实体，并且它是必须运行的JMS 服务器。因此，当我们说 JMS 时，我们指的是提供者实现的一组 API（更技术性地说是接口）。所以基本上供应商编写自己的 JMS 实现。例如，Active MQ 是一个 JMS 服务器，由Apache(provider)提供在某种程度上是正确的。有不同的模型可供遵循。 JMS 服务器保持套接字打开。每当发送方客户端必须发送消息时，它只需打开与套接字的连接并发送消息。接收行为的方式完全不同。你有拉力和推力。在推送服务器中，一旦收到消息，就会将消息推送到实时接收者客户端。这也称为异步模式。在拉模型中，客户端接收者向服务器发送请求以获取消息（同步模式）。
正如我在上一点中提到的，这取决于您使用的型号。接收器将在拉模型（同步接收）中被阻止。这也发生在会话线程中，而不是主线程中。
是的，在拉模型的情况下，客户端将不断轮询。通常会有一个超时，之后客户端将被终止。
使用异步模式。您只需注册一个MessageListener，当服务器上有消息可用时，它将在其覆盖的onMessage(Message msg)上接收消息。
这确实是供应商需要担心的问题。当您说所有订阅者都收到消息时，您指的是 PUBSUB 通信模型（其他为 PTP）。在 PUBSUB 中，发送到某个主题的消息将被传递给订阅该主题的所有订阅者。
可靠性？并非总是如此。同样，这取决于用例。您可以拥有持久消息以及非持久消息。对于持久消息，消息存储在数据库（文件或其他）中，并确保其传递。如果是非持久消息，则没有这样的保证。服务器故障可能会导致消息丢失。
Let's get the terminologies right first. You cannot say
JMS Provider must be runningbecause provider is an entity that has built the JMS server and it is the JMS server that must be running. Hence, when we say JMS, we mean a set of APIs (more technically - interfaces) which providers implement. So basically providers write their own JMS implementation. For example,Active MQ is a JMS serverthat is provided byApache(provider)True to some extent. There are different models that are followed. JMS server keeps a socket open. Whenever a sender client has to send message it simply opens a connection to the socket and sends the message. How receive behaves is entirely different. You have pull and push. In push server will push the messages to the live receiver client as soon as it receives message. This is also called asynchronous mode. In pull model client receiver sends request to server to get messages (synchronous mode).
As I mentioned in previous point it will depend on the model you are using. Receiver will get blocked in pull model (synchronous receive). Also this happens in Session thread, not the main thread.
Yes, client will continuously poll in case of pull model. Generally there is a timeout after which client will be terminated.
Use asynchronous mode. You simply have to register a MessageListener and it will receive message on it's overridden onMessage(Message msg) when there is availability of messages on server.
It is really a question for providers to worry about. When you say a message is received by all subscribers you are referring to PUBSUB model of communication (other being PTP). In PUBSUB message sent to a topic will be delivered to all the subscribers subscribed to that topic.
Reliability? Not always. Again, this depends on the use case. You can have persistent as well as non persistent Messages. In case of persistent messages, messages are stored in DB (file or others) and it's delivery is ensured. In case of non persistent messages there is no such guarantee. Server failure may result in message loss.
JMS 支持使用同步方法（在有或没有超时阻塞线程的情况下接收）或使用事件驱动的回调（异步消息侦听器）进行消息消费。
您可以决定哪种方法更适合您的需求，但您可能还需要查看实际的实现。例如，某些 JMS 实现为 receive() 执行网络往返，因此最好与超时或侦听器一起使用。
使用消息侦听器的线程行为和消息接收的暂停并不像使用阻塞接收调用那样容易控制。通常，大多数控制是通过拥有自己的带有超时的阻塞 receive() 调用池来实现的，并调度给您的工作人员。
JMS support message consumption with a synchronous method (receive with and without timeout blocking your thread) or with a event driven callback (async message listener)).
You can decide which method better fits your needs, but you also may need to have a look at the actual implementation. For example some JMS implementations do a network roundtrip for the receive() and therefore are better used with a timeout or with the listener.
With the message listener thread behaviour and pausing of message receipt are not so easyly controled as with a blocking receive call. Typically most control is achieved by having your own pool of blocking receive() calls with timeouts, dispatching to your workers.
我认为应该提到队列和主题之间的区别，因为消息传递方式存在重要差异。
队列：只有一个客户端会收到一条消息。为了横向扩展，您可以将 10 个客户端全部连接到同一个队列 - 但只有其中一个会收到特定消息。如果没有客户端连接，消息将保留在队列中，直到有人连接或消息超时。
主题：所有客户端都会收到每条消息的副本。通常用于订阅者场景，其中许多端点可能对每条消息感兴趣。持久订阅者甚至可能会宕机一段时间；消息将被保留，直到订阅者再次启动或消息超时。如果没有客户端连接并且没有持久订阅者，消息将被丢弃。
I think the difference between Queue and Topic should be mentioned since there are important differences in the way messages are delivered.
Queue: only one client will receive a message. To scale out, you can for example have 10 clients all connected to the same queue - but only one of them will receive a particular message. If no clients are connected, message will stay on the queue until someone connects or the message times out.
Topic: all clients will receive a copy of each message. Typically used in a subscriber scenario where many endpoints are potentially interested in each message. A durable subscriber can even be down for a while; message will be kept until subscriber is up again or the message times out. If no clients are connected and there are no durable subscribers, message will be dropped.
JMS 中有两种类型的消息传递域。
输入PTP模型，一条消息仅传递给一个接收者。这里，队列被用作M消息O面向M中间件（MOM）。
队列负责保存消息，直到接收者准备好。
在PTP模型中，发送方和接收方之间不存在时序依赖性。
在 Pub/Sub 模型中，一条消息会传递给所有订阅者。这就像广播。这里，Topic作为一个面向消息的中间件，负责保存和传递消息。
在PTP模型中，发布者和订阅者之间存在时间依赖性。
JMS 编程模型
source
Message Driven Bean (MDB)
There are two types of messaging domains in JMS.
In PTP model, one message is delivered to one receiver only. Here, Queue is used as a Message Oriented Middleware (MOM).
The Queue is responsible to hold the message until receiver is ready.
In PTP model, there is no timing dependency between sender and receiver.
In Pub/Sub model, one message is delivered to all the subscribers. It is like broadcasting. Here, Topic is used as a message oriented middleware that is responsible to hold and deliver messages.
In PTP model, there is timing dependency between publisher and subscriber.
JMS Programming Model
source
Message Driven Bean (MDB)