I was reading RPC-Model in AMQP with RabbitMQ. The tutorial creates a temporary queue and also correlationId. Temporary queues are unique, so why should we need correlationId? I'm a JMS guy, in JMS we do request/response in two ways:
create temporary queue for each request/response
create one response queue and use correlationId and message selector.
can someone explain why do we need both temporary queue and correlationId in AMQP RPC model? It seems AMQP does not have something like message selector. Am I right?
Correct, temporary queues are unique to the client making the RPC request. We could create the RPC client to have a unique queue for each unique request it makes, but that would be inefficient - see the first paragraph of CorrelationId here:
In the method presented above we suggest creating a callback queue for every RPC request. That's pretty inefficient, but fortunately there is a better way - let's create a single callback queue per client.
So a better way is to have one queue which the RPC client gets response back on and uses the correlationId to match the request that the RPC client makes to the result that the RPC server sends back.
...having received a response in that queue it's not clear to which request the response belongs. That's when the correlation_id property is used. We're going to set it to a unique value for every request. Later, when we receive a message in the callback queue we'll look at this property, and based on that we'll be able to match a response with a request. If we see an unknown correlation_id value, we may safely discard the message - it doesn't belong to our requests.
So referencing the Summary section of the RPC tutorial:
- when a client starts it creates an exclusive and unique queue
- when it sends an RPC request it sets the reply_to which is the queue name (so the server knows which queue to send a response to) and also sets a correlationId which is a unique val for each RPC request
- the request is sent to the RPC queue
- the RPC worker (or server) receives the request processes it then using the reply_to value sends the response back to the client, it also sets the correlationId
- the RPC client waits for a response and when it receives one uses the correlationId to MATCH the response with the request
