Implement synchronous request / response logic in JmsTemplate [SPR-3332]

[spring-projects-issues]

David J. M. Karlsen opened SPR-3332 and commented

Add support for synchronous send and receive in JmsTemplate, something like this:

Object response = doSendAndReceive( String requestDestination, String responseDestination, Object value )
throws JmsException

which uses SimpleMessageConverter to convert value to message, destinationResolver to resolve response and request destinations, set's JmsReplyTo to responseDestination, and uses the generated messageId to select the responsemessage, waiting for getReceiveTimeout() milliseconds to receive.

This is a very common usecase - and I think it should be supported directly by the framework - without having to use Jencks or the likes.

---

Affects: 2.0.3

Attachments:

• JmsTemplateSynchronous.txt (1.35 kB)
• sessioncallbackcode.txt (1.45 kB)

Issue Links:

• INT-2683 Enable cachability of consumers for reply-side of JmsOutboundGateway
• Update JmsMessagingTemplate to support MessageRequestReplyOperations [SPR-12037] #16653 Update JmsMessagingTemplate to support MessageRequestReplyOperations
• Support "request message id as response correlation id" in MessageListenerAdapter [SPR-4647] #9324 Support "request message id as response correlation id" in MessageListenerAdapter

21 votes, 25 watchers

[spring-projects-issues]

Greg Matthews commented

I would have thought the code to do this was somewhere in Spring in some form or another, given that org.springframework.jms.remoting.JmsInvokerServiceExporter handles request/response.

[spring-projects-issues]

David J. M. Karlsen commented

Yes, it's supported on the server-side in both JmsInvokerServiceExporter and in MessageListenerAdapter - but not out of the box on the client (initiating) side. There you have to call execute( SessionCallback ). And therefore you have to do all the converting, destination resolving and so on yourself. It would be extremely handy if this could be implemented in the 2.5 series!

[spring-projects-issues]

David J. M. Karlsen commented

It can be added that correlationId is usually produced by the JMS vendor AFTER sending the message - none of the methods in JmsTemplate provide easy access to the message after it's sendt today.

[spring-projects-issues]

Juergen Hoeller commented

OK, let's see what we can do in time for the 2.5.2 release :-)

Juergen

[spring-projects-issues]

Juergen Hoeller commented

A difference between JmsInvokerClientInterceptor and your suggestion is that the former creates a temporary response queue that it listens to. So it doesn't rely on a given response queue plus the generated message id; it rather relies on a specific temporary response queue.

I'm inclined to take JmsInvokerClientInterceptor's strategy as the role model for equivalent functionality in JmsTemplate. Would this be sufficient for your purposes? Any negative impact when using a temporary response queue?

Juergen

[spring-projects-issues]

Magnus Heino commented

+1 for using temporary queues

[spring-projects-issues]

David J. M. Karlsen commented

Juergen: Unfortunately - yes.
We use JMS to talk to our EIS (CICS) mainframe system:
Different "islands" of clients (the EIS system is needless to say serving a lot of different clients) expects response to several different queues (while the EIS system is usually listening only to one specific queue).
And again - within one "island" several clients would be listening on the same queue for different responses.

AFAIK this requires a specific queue, and is a quite common pattern in large systems like this.

[spring-projects-issues]

David J. M. Karlsen commented

It can also be added that if it's possible to get hold of the Message after it is sent this is enough for users which have the same issues as me to implement this themselves by:

doSend
getMessageId of sent message
and then doReceiveSlecetedAndConvert( id)

[spring-projects-issues]

Juergen Hoeller commented

David, do you have the rough SessionCallback code available - a sketch of the code that you're presently using? It would be great to review this before baking such functionality into JmsTemplate itself. I intend to add this in two flavors: with a temporary queue as well as with a specified queue plus message id for filtering.

Juergen

[spring-projects-issues]

David J. M. Karlsen commented

Attaching code as requested.
i extended the JmsTemplate102 class - adding the method as shown.

[spring-projects-issues]

Todd Fredrich commented

I took a different tack in extending JmsTemplate.

[spring-projects-issues]

Jeremy Davis commented

So, a year later has there been any action on this?

[spring-projects-issues]

David J. M. Karlsen commented

https://issues.apache.org/activemq/browse/CAMEL-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56781#action_56781 Might be a relevant resource for the handling.

[spring-projects-issues]

Mark Fisher commented

Thanks David. We have a good starting point for this feature that is currently being used in Spring Web Services and Spring Integration. The use of CorrelationID with a fallback to MessageID is a relevant topic as well. When thinking of this from the perspective of refactoring something like Spring Integration's outbound JMS Gateway so that it simply delegates to JmsTemplate in the future, a number of options come to mind. First, we'll want to preserve at least the options that are supported there. That means we need to allow either 1) TemporaryQueue per-request or 2) shared response Destination with a correlation strategy.

For #2 above, we could even define an actual CorrelationStrategy interface. The default implementation might be based on a CorrelationID MessageSelector, or we might want to consider a callback/Map approach. The following Spring Integration forum thread is relevant for the discussion: http://forum.springsource.org/showthread.php?t=82368

The bottom line is that neither TemporaryQueues or MessageSelectors are ideal on a per-request basis, so we should be sure to support additional options.

[spring-projects-issues]

Stéphane Nicoll commented

it probably goes beyond JmsTemplate in my opinion if you want flexibility. We have implemented something like this based on JMS template and here are the things that we support:

1. Send multiple messages and aggregate their response. Once you enter the synchronous request mode, you might want to wait for X requests, not one (and of course you don't want one listener and one session per message)
2. Timeout policy. Sometimes you can determine through custom means if the remote worker is still up or not.
3. Completion policy. The responses may not match the requests. In other words, you might send 10 requests and get 2 replies.

We have implemented such a mechanism, relying on a temporary queue to collect the replies. It is working fine for us and it is available with the ASL v2 license on github. We actually use this internally to offer distributed execution of the partitions of a Step in Spring Batch

See https://github.com/snicoll/spring-batch-admin/tree/execution-jms/spring-batch-integration/src/main/java/org/springframework/batch/execution/jms/partition/aggregation

If someone is interested by such a high level service on top of Jms template and you guys decide it's not a good candidate for the Spring framework we can try to put it somewhere so that others can use it.