[AMQP-72] Add receive-and-reply convenience to RabbitTemplate Created: 31/Oct/10  Updated: 10/Jan/14  Resolved: 05/Jan/14

Status: Closed
Project: Spring AMQP
Component/s: Core
Affects Version/s: None
Fix Version/s: 1.3.0.M1

Type: New Feature Priority: Major
Reporter: Dave Syer Assignee: Artem Bilan
Resolution: Complete Votes: 1
Labels: PullRequest
Remaining Estimate: 0d
Time Spent: Not Specified
Original Estimate: 0d


RabbitTemplate has a producer send-and-receive convenience (unlike the JMS cases), but it is pretty hard to use without the mirror image for the consumer.

Comment by Artem Bilan [ 20/Dec/13 ]

PR: https://github.com/spring-projects/spring-amqp/pull/138

Comment by Pulkit Singhal [ 21/Dec/13 ]

I used 1.3.0.BUILD-SNAPSHOT artifact built from commit [2589e58] like so:

            String queueName = "blah";
            rabbitAdmin.declareQueue(new Queue(queueName, true));
                    new ReceiveAndReplyCallback<RequestDelegate, ResponseDelegate>() {
                        public ResponseDelegate handle(RequestDelegate requestDelegate) {
                            System.out.println("RABBIT PAYLOAD:\n" + requestDelegate.toString());
                            ResponseDelegate responseDelegate =
                                    new ResponseDelegate(200, null,"No soup for you!"); // default reply
                            return responseDelegate;

in order to send back a dummy message to the producer.

On the producer side I am using 1.2.0.M1 which gets the message but then somewhere along the line ... it trips-up with a NPE (NullPointerException) on Line 790 of RabbitTemplate class. I hope the links to the eclipse debug screenshots are self-explanatory ... the correlation id is null.

Comment by Pulkit Singhal [ 21/Dec/13 ]

Probably the logic for something like the postProcessResponse from MessageListenerAdapter which "sets the response's correlation id to the request message's correlation id, if any" ... isn't wired into the receiveAndReply* methods ... yet?

Comment by Pulkit Singhal [ 21/Dec/13 ]

So instead of:

if (reply != null) {
	Address replyTo = replyToAddressCallback.getReplyToAddress(message, reply);
	RabbitTemplate.this.doSend(channel, replyTo.getExchangeName(), replyTo.getRoutingKey(),
			RabbitTemplate.this.convertMessageIfNecessary(reply), null);

Maybe something like:

if (reply != null) {
	Address replyTo = replyToAddressCallback.getReplyToAddress(message, reply);
	Message replyAsMessage = RabbitTemplate.this.convertMessageIfNecessary(reply);
	RabbitTemplate.this.postProcessResponse(message, replyAsMessage);
	RabbitTemplate.this.doSend(channel, replyTo.getExchangeName(), replyTo.getRoutingKey(),
			replyAsMessage, null);
Comment by Artem Bilan [ 22/Dec/13 ]

Good catch, Pulkit!
You are right: `correlationId` has be covered too.
So, it is pushed to PR https://github.com/spring-projects/spring-amqp/pull/138
You can provide your feedbacks in PRs as well.

Thank you for your contribution!

Comment by Pulkit Singhal [ 04/Jan/14 ]

Hello Artem,

I was building your github source to my local maven repo until recently but 1.3.0.BUILD-SNAPSHOT was published on Jan 3rd here:
and my maven build picked up on this.

The interesting part is that org.springframework.amqp.core.ReceiveAndReplyCallback cannot be found in the snapshot release published on Jan 3rd. Is it simply not merged in there yet or did you change any names for your implementation class recently?

Comment by Artem Bilan [ 04/Jan/14 ]

No-no. I wasn't merged yet. You should pick my branch up one more time and rebuild it again.
However, I think it will be merged on Monday, so it really will be avaliable from from our repo in the 1.3.0.BUILD-SNAPSHOT

Comment by Gary Russell [ 05/Jan/14 ]

Merged, but there was a failed test on the CI build...


6 replies were null due to missing correlation data...

2014-01-05 11:30:42,765 ERROR SimpleAsyncTaskExecutor-1 [org.springframework.amqp.rabbit.core.RabbitTemplate] - <No correlation header in reply>

Notice that the seventh message has correlation data in header 'CorrelationKey'.

This is because the key was set after the launch of the first 10 execs.

Moved the setting of the key.

Comment by Gary Russell [ 05/Jan/14 ]


Generated at Sat Feb 23 19:51:47 UTC 2019 using JIRA 7.9.2#79002-sha1:3bb15b68ecd99a30eb364c4c1a393359bcad6278.