How does JMS Receive work internally?

Question

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.

Answer 1

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:- MessageConsumer and MessageListener. MessageConsumer class allows a JMS client to synchronously receive JMS messages by calling any of its receive() method. This call will be blocking thread until a message is received. Otherwise, asynchronous receive can be made by registering an object of MessageListener with MessageConsumer. 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:- MessageConsumer API has two variants of receive: receive() and receive(long timeout). The latter variant lets MessageConsumer thread 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.

Answer 2

Question 1: Is my basic understanding of JMS correct?

Let's get the terminologies right first. You cannot say JMS Provider must be running because 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 server that is provided by Apache(provider)

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).

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).

Does receive (typically) block if no messages are avaiable?

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.

If so, how is blocking achieved? Does the client continuously poll for messages?

Yes, client will continuously poll in case of pull model. Generally there is a timeout after which client will be terminated.

If not, how does one ensure messages are received in a timely manner, without impacting performance?

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.

Question 3: How does JMS scale?

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.

Question 3b: How does a JMS implementation ensure reliable delivery in a scaled environment?

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.

Answer 3

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.

Answer 4

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.

Answer 5

There are two types of messaging domains in JMS.

1. Point-To-Point(PTP) Messaging Domain
2. Publisher/Subscriber Messaging Domain

---

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)

• MDB is a bean that contains business logic. But, it is invoked by passing the message. So, it is like JMS Receiver.
• MDB asynchronously receives a message and processes it.
• MDB receives message from queue or topic.
• MDB is like stateless session bean that encapsulates a business logic and does not maintain a state of the bean.