[rabbitmq-discuss] about RabbitMQ + HTTP Server configuration

Marek Majkowski majek04 at gmail.com
Thu Nov 11 14:19:44 GMT 2010

On Thu, Nov 11, 2010 at 08:16, Madalin Popa <madalin at sellerengine.com> wrote:
> I have a RabbitMQ server with 2 channels (tx, rx), consuming requests
> (rx channel) from a HTTP server and passing them to a pool of
> slaves...The slaves, when they finish their work, pass the result back
> on RabbitMQ tx channel, from where the response needs to be mapped back
> to initial HTTP request. Are there any natural/out of the box solutions
> for this final part of mapping the response received from tx queue back
> to HTTP requester?

What we usually do to achieve rpc:
 1. On every Requester we create an anonymous queue.
     Let's say that this queue is randomly named 'req-1'
 2. Requester publishes a message to the queue shared by the workers.
    This message contains usual stuff, like the description of the
    work to do. But except from that, it should have two headers
    set: 'reply_to' -> set to 'req-1' and 'correlation_id' -> set to a
random value.
3 . The worker picks up the task, does what it should do,
    and after it's done, it's ready to respond.
    The response should go to the queue named by 'reply_to' header
    in the request. Don't forget also to copy over the 'correlation_id' header.
4. Requester looks at his queue, sees a reply.
    Based on 'correlation_id' it's able to match it to the request.
5. Tadam. Job done.

Using this schema you:
 - need one queue per requester
 - don't have to create a single queue per every request
 - you're free to trash responses that come with invalid 'correlation_id' tag.


More information about the rabbitmq-discuss mailing list