skip to content

What is JmsMessagingTemplate, how does it differ from JmsTemplate, and how does synchronous JMS request-reply work?

level: seniorimportance: should knowfreq 40%

answer

  1. JmsMessagingTemplate = adapter over JmsTemplate, uses Message<T> + headers
  2. spring-messaging abstraction, provider-neutral
  3. request-reply: JMSReplyTo + JMSCorrelationID + temp queue
  4. sendAndReceive / convertSendAndReceive block up to receiveTimeout
  5. @JmsListener returning a value auto-replies (or @SendTo)

basics

~20 s

JmsMessagingTemplate wraps a JmsTemplate but works with Spring's spring-messaging Message<T> abstraction (payload + headers) instead of raw JMS Message. For request-reply, convertSendAndReceive sends a message with a JMSReplyTo/correlation ID, then blocks waiting for the correlated response on a reply destination.

solid answer

~50 s

JmsTemplate is the low-level JMS-native helper (works with jakarta.jms.Message, MessageConverter, DestinationResolver). JmsMessagingTemplate is a thin adapter over a JmsTemplate that speaks Spring's provider-agnostic org.springframework.messaging.Message<T> — a payload plus a MessageHeaders map — using a MessageConverter (default SimpleJmsHeaderMapper + a payload converter). You get convertAndSend/receiveAndConvert working with plain payloads and headers, and a unified API across JMS/AMQP/Kafka style. For synchronous request-reply, both templates expose sendAndReceive / convertSendAndReceive: the template sends the request, sets JMSReplyTo to a (usually temporary) reply queue, correlates the response by JMSCorrelationID (or the request's JMSMessageID), and blocks up to receiveTimeout for the matching reply. The responder side reads JMSReplyTo and sends the answer there with the correlation id set — a @JmsListener can return a value to do this automatically. It's an in-band RPC over messaging; use sparingly because it couples caller latency to the responder.

code

java · 26 lines
java
// --- Caller: synchronous request-reply ---
@Service
public class PricingClient {
    private final JmsMessagingTemplate messaging;

    public PricingClient(JmsMessagingTemplate messaging) {
        // ensure the backing JmsTemplate has a finite receiveTimeout
        this.messaging = messaging;
    }

    public Quote requestQuote(QuoteRequest req) {
        // sends request, sets JMSReplyTo (temp queue), blocks for correlated reply
        return messaging.convertSendAndReceive("pricing.request", req, Quote.class);
    }
}

// --- Responder: returning a value auto-replies to JMSReplyTo ---
@Component
public class PricingService {
    @JmsListener(destination = "pricing.request")
    public Quote onRequest(QuoteRequest req) {   // return value -> reply
        return new Quote(req.symbol(), computePrice(req));
    }

    private double computePrice(QuoteRequest req) { return 42.0; }
}

go deeper

for a junior

Know JmsMessagingTemplate deals in payload+headers Message<T> and that JMS request-reply needs a reply destination.

for a middle

Explain the wrap-over-JmsTemplate relationship and the JMSReplyTo + JMSCorrelationID mechanism.

for a senior

Detail temporary reply queues, correlation via selector, sendAndReceive/convertSendAndReceive timeouts, and @JmsListener auto-reply/@SendTo.

for a principal

Weigh synchronous request-reply's thread/coupling cost vs true async and vs HTTP, and the temp-queue/caching-connection interplay.

**Two template layers.** - `org.springframework.jms.core.JmsTemplate` — JMS-native. Deals in `jakarta.jms.Message`, `Destination`, `MessageConverter`, `DestinationResolver`. This is what everything below is built on. - `org.springframework.jms.core.JmsMessagingTemplate` — implements `JmsMessageOperations`, part of Spring's **spring-messaging** abstraction. It wraps a `JmsTemplate` and exposes operations in terms of `org.springframework.messaging.Message<T>`: a generic **payload** plus **MessageHeaders** (an immutable key/value map). It converts between the messaging `Message<T>` and a JMS `Message` using a `MessageConverter` and a `JmsHeaderMapper` (`SimpleJmsHeaderMapper`) that maps standard JMS headers (JMSCorrelationID, JMSReplyTo, JMSType, JMSPriority…) to/from header keys. **Why JmsMessagingTemplate exists.** It gives a *provider-neutral* programming model — the same `Message<T>` / header style you'd use with `RabbitMessagingTemplate` or Spring Integration — so business code isn't tied to raw JMS types, and headers travel as a clean map. Under the hood it still delegates to a `JmsTemplate` you supply (or one it builds from a `ConnectionFactory`). **Sending/receiving with it.** - `convertAndSend(destination, payload)` / `convertAndSend(dest, payload, headersMap)` - `receiveAndConvert(destination, Class<T>)` — returns a typed payload. - Works with `MessagePostProcessor` equivalents and a `MessageConverter` (Spring Boot auto-configures a `JmsMessagingTemplate` bean when a `JmsTemplate` exists). **Synchronous request-reply (the RPC pattern).** JMS is inherently one-way, but a request/response can be built: 1. **Caller** sends the request message and sets `JMSReplyTo` to a reply `Destination`. Spring typically creates a **temporary queue** (`session.createTemporaryQueue()`) unique to the caller, so replies can't be picked up by anyone else. 2. The template records a **correlation id** — either it sets `JMSCorrelationID` explicitly, or it uses the request's broker-assigned `JMSMessageID` and matches the reply's `JMSCorrelationID` against it. 3. Caller **blocks** on a consumer of the reply destination (bounded by `receiveTimeout`) using a selector on the correlation id. 4. **Responder** consumes the request, reads `JMSReplyTo`, produces a response, copies the correlation id, and sends the response to that reply destination. 5. Caller's blocking receive returns the correlated reply; the template converts it to the return payload. API surface: `JmsTemplate.sendAndReceive(destination, MessageCreator)` returns the reply `Message`; `JmsMessagingTemplate.sendAndReceive(dest, Message<?>)` and `convertSendAndReceive(dest, request, Class<T>)` do it at the messaging-abstraction level and give you a typed payload. **Responder with @JmsListener.** A listener method that **returns a value** triggers Spring's automatic reply: the `JmsListenerContainer`'s `MessagingMessageListenerAdapter` sends the return value to the request's `JMSReplyTo` (default) or to a `@SendTo("...")` destination, copying the correlation id. So you rarely hand-wire the responder side. **Key gotchas.** - **receiveTimeout is critical:** the caller blocks; if the responder is down or slow the caller thread is tied up until the timeout, then gets null / an exception. Always bound it. - **Temporary queues vs caching:** temporary reply queues live for the connection's lifetime and are auto-deleted. With a `CachingConnectionFactory` the shared connection keeps them alive, but you must ensure the reply consumer uses the *same* connection that owns the temp queue — otherwise resolution fails. Spring's `sendAndReceive` handles this within one operation. - **Correlation collisions:** if you use a shared (non-temporary) reply queue for many callers, you MUST correlate by id (selector) or replies get delivered to the wrong caller. Temporary per-request queues avoid this at the cost of creating queues. - **Throughput/coupling:** synchronous request-reply turns async messaging into blocking RPC — it serializes caller latency on responder latency and holds threads. Prefer true async (fire-and-forget + callback/event) unless you specifically need a synchronous answer and want the decoupling/load-leveling a broker gives over direct HTTP. - **Not the same as receiveAndConvert:** `receiveAndConvert` just pulls the next message off a destination; request-reply additionally correlates a specific response to a specific request. **When to use.** JmsMessagingTemplate when you want the spring-messaging `Message<T>`/header model or portability across brokers; plain JmsTemplate when you're fine with JMS-native types. Request-reply when a caller genuinely needs a synchronous answer but you still want broker-mediated decoupling, back-pressure, and location transparency instead of a direct synchronous HTTP call.

  • How does the caller match the correct response to its request in JMS request-reply?
    The request carries a JMSReplyTo destination (often a temporary queue) and a correlation id. The responder copies the request's id into the reply's JMSCorrelationID. The caller consumes the reply destination, correlating by that id (a message selector), so it only receives its own response.
  • How does a @JmsListener know where to send its return value?
    By default the MessagingMessageListenerAdapter sends the returned object to the request message's JMSReplyTo destination, copying the correlation id. A @SendTo("dest") annotation overrides the target destination explicitly.
  • Why prefer synchronous JMS request-reply over a direct HTTP call — or not?
    Broker-mediated request-reply adds decoupling, location transparency, load-leveling, and retry/DLQ semantics. But it still blocks the caller on the responder and consumes threads/temp queues, so for low-latency synchronous needs a direct HTTP call is often simpler; use JMS request-reply when you want the broker's decoupling with a synchronous contract.

saying these in an interview costs you the question

  • Saying JmsMessagingTemplate replaces/is unrelated to JmsTemplate (it wraps and delegates to one)
  • Thinking request-reply works without a reply destination or correlation id
  • Claiming JMS supports request-reply natively as a single call with no reply queue
  • Confusing receiveAndConvert (pull next message) with request-reply correlation
  • Using a shared reply queue for many callers without correlating by id

context

resolving links…