Timeouts waiting for responses

[Gary Russell]

You don't need a replyChannel on your gateway; because you don't have a reply-channel on your outbound gateway, the framework knows it needs to send the reply to the gateway.

The reply queue on the rabbit template is unrelated to the framework reply channel. The reply-queue is an AMQP (rabbit) Queue on which all replies are sent. This is to avoid the overhead of creating a new queue for each reply.

It is a new feature in the 1.1.0 release that came out last week.

[mberg]

Thanks Gary.

There is a replyTo message header, a reply-channel on the outbound gateway and a reply queue on the template.

I know there's probably not a much better way to do this, but it can be confusing to a newbie like myself.. :-)

What header parts are relevant with respect to message routing? I know replyTo stores the queue to which to send the reply to. But if that queue has a fixed name, how does the system know which client should pull the reply off the queue? I mean, if multiple clients are talking to my server, and the reply queue has a fixed name, how are messages routed out to each client?

[mberg]

After adding the reply-queue header to my rabbit:template tag, I'm getting this error:

ERROR org.springframework.amqp.rabbit.core.RabbitTemplat e [SimpleAsyncTaskExecutor-1] RabbitTemplate - No correlation header in reply

No hits on google for this error ... perhaps you can help?

[Gary Russell]

Oops; sorry; for this to work out of the box, you need Spring Integration 2.2.0.M1.

However, you can make it work with earlier versions by mapping the headers on the server side. If you look at debug logs on the server, you will see that some headers are being dropped; you need to add mappings for

spring_reply_correlation
spring_reply_to

[mberg]

Adding the mapping solved the problem. I guess everything is working as it should now, thanks for your help Gary and Mark :-)

[ygowda]

Each temporary queue should live until a reply Message is received or as long as the timeout, whichever is longer. Then, it is deleted.

Are you actually witnessing something different?

Hi Mark,
Temporary Reply Queue is not getting deleted after it received the message. I'm using Spring amqp template to send and receive the message.

Below is the code snippet

context = new AnnotationConfigApplicationContext(RabbitConfigura tion.class);

Queue replyQueue = (Queue)context.getBean("springAmqpQ");
System.out.println("Reply Queue Name : " + replyQueue.getName());
RabbitTemplate template = (RabbitTemplate)context.getBean("amqpTemplate");
template.setReplyTimeout(120000);
template.setReplyQueue(replyQueue);
//template.convertAndSend(exchange, routingKey, createMessage(reportDbPing.getBytes()));
template.send(exchange, routingKey, createMessage(reportDbPing.getBytes()));
System.out.println("Message sent and went for a sleep.....");
Thread.sleep(120000);
System.out.println("Wake up from a sleep ready to consume Message");
Message message = template.receive(replyQueue.getName());

One more question, on how to set ack or Nack to the RabbitMq broker using AmqpTemplate? Or AmqpTemplate.receive() implicitly does autoAck??

Thanks in advance.

[Gary Russell]

The template doesn't use temporary queues when you specify a replyQueue. See the java docs...

	/**
	 * A queue for replies; if not provided, a temporary exclusive, auto-delete queue will
	 * be used for each reply.
	 *
	 * @param replyQueue the replyQueue to set
	 */

However, the replyQueue (or temporary reply queue) is only used by the template when you use the ...sendAndReceive(...) methods. Also, an explicit replyQueue requires a listenerContainer to handle the replies. Ack behavior is configured on the listener container. Besides transactions, there is no way to control the ack behavior in receive().

[ygowda]

The template doesn't use temporary queues when you specify a replyQueue. See the java docs...

	/**
	 * A queue for replies; if not provided, a temporary exclusive, auto-delete queue will
	 * be used for each reply.
	 *
	 * @param replyQueue the replyQueue to set
	 */

However, the replyQueue (or temporary reply queue) is only used by the template when you use the ...sendAndReceive(...) methods. Also, an explicit replyQueue requires a listenerContainer to handle the replies. Ack behavior is configured on the listener container. Besides transactions, there is no way to control the ack behavior in receive().

Thanks Gary,

I see the behavior as you said, as temporary queue requires Ack, I assume the autoAck is set to true on the channel.