Improve performance and simplicity of RPC clients by sending replies direct to a waiting channel.
RPC is a popular pattern to implement with a messaging broker like RabbitMQ. The typical way to do this is for RPC clients to send requests to a long lived server queue. The RPC server(s) read requests from this queue and then send replies to each client using the queue named by the client in the reply-to header.
But where does the client's queue come from? The client can declare a single-use queue for each request-response pair. But this is inefficient; even a transient unmirrored queue can be expensive to create and then delete (compared with the cost of sending a message). This is especially true in a cluster as all cluster nodes need to agree that the queue has been created, even if it is unmirrored.
So alternatively the client can create a long-lived queue for its replies. But this can be fiddly to manage, especially if the client itself is not long-lived.
The direct reply-to feature allows RPC clients to receive replies directly from their RPC server, without going through a reply queue. ("Directly" here still means going through AMQP and the RabbitMQ server; there is no separate network connection between RPC client and RPC server.)
To use direct reply-to, an RPC client should:
The RPC server will then see a reply-to property with a generated name. It should publish to the default exchange ("") with the routing key set to this value (i.e. just as if it were sending to a reply queue as usual). The message will then be sent straight to the client consumer.
If the RPC server is going to perform some expensive computation it might wish to check if the client has gone away. To do this the server can declare the generated reply name first on a disposable channel in order to determine whether it still exists. Note that even if you declare the "queue" with passive=false there is no way to create it; the declare will just succeed (with 0 messages ready and 1 consumer) or fail.