Handle request-reply with RabbitMQ direct reply-to

[acogoluegnes]

JMS usually implements request-reply with a temporary queue shared between the client and the server sides of the system, it would be good to be able to use RabbitMQ's direct reply-to mechanism to implement this.

We should also ensure this works out of the box with Spring's JmsTemplate, see #47.

[wheezil]

Sorry about previous comment, that should have been for #47

[michaelklishin]

We don't need any more drama and attacks on our team. What we do need is specific suggestions as to why Direct Reply-to might not be a good fit or alternative ideas. Either contribute productively or this issue will be locked.

@acogoluegnes we can do a couple day long spike to see if there are any issues with this approach then confirm our findings with the Spring team. WDYT?

[wheezil]

I am curious, will direct-replyto solution present as an implementation-specific API in the RabbitMQ JMS provider or will it follow the getReplyTo() + send() model that seems to prevail in the JMS RPC examples? While I do not understand the specifics of #47 and why the queue is "redeclared" on reply, is the naive approach of having getReplyTo() call setDeclared() on the returned queue viable? If that is not desirable as a default, can it be an option? I would need to dig into code base to see if RMQs implementation of Message makes this possible. John

[michaelklishin]

Labelled as bug as we expect to cover issues suc has #47 with it.

[michaelklishin]

With Direct Reply-to the client can avoid declaring a response queue if it follows a certain convention. I'm not a JMS expert but AFAICT it should be possible to keep that an implementation detail instead of introducing a new API. The spike I suggested above can in part focus on that.