Use one RabbitTemplate for both `send()` and `sendAndRecieve()` with a fixed reply queue. [AMQP-480]

[spring-operator]

Scott Frederick opened AMQP-480 and commented

It is currently not possible to use the same instance of a RabbitTemplate to both send() and sendAndRecieve() using multiple fixed reply queues. When using send(), the fixed reply queue can be set on either the message or the RabbitTemplate, allowing the same template to be used for sending messages with replies going to a queue specified in the message. When using sendAndRecieve() the fixed reply queue can only be set on the RabbitTemplate, not on the message, so a unique template must be used for each fixed reply queue.

---

No further details from AMQP-480

[spring-operator]

Gary Russell commented

Hi Scott,

I don't think we could do that very easily; the problem is that we'd have to spin up a listener container for each queue; right now we initialize the listener container during initialization.

I suppose for "advanced users" we could just allow it, but you'd be responsible to configure each of the reply listener containers.

That said, many (all?) of the reasons for adding the fixed reply queue mechanism (the cost of creating temporary queues) has now been resolved in RabbitMQ.

Starting with 3.4, rabbit now has a Direct reply-to mechanism using a "dummy" internal reply queue for each channel.

We switched the RabbitTemplate to support that if it's running against a 3.4.x broker in 1.4.1. See #1983 and http://docs.spring.io/spring-amqp/docs/latest-ga/reference/html/amqp.html#direct-reply-to .

Let us know if you still want us to pursue your requested feature.

Gary

[spring-operator]

Scott Frederick commented

OK, that makes sense. As a somewhat novice spring-amqp and RabbitTemplate user, the difference between send() and sendAndReceive() behavior just caught me by surprise.

In fact, I switched to using direct reply-to when I figured out that the alternative was to have multiple RabbitTemplates configured, one for each fixed reply queue. So I don't have an immediate need for this feature, I just thought it might make sense for other use cases.

[spring-operator]

Gary Russell commented

I think we can do this now, with the new DirectMessageListenerContainer because it allows us to efficiently add queues dynamically.