[rabbitmq-discuss] "Returning" values

Mon Mar 29 16:06:10 BST 2010

On Sun, Mar 28, 2010 at 11:56 PM, Andreas Jung <lists at zopyx.com> wrote:
> Hi there,
>
> I am aware that a message queue does not support returning value. Is there a
> pattern for the following usecase:
>
> User submits a data set through the browser to the backend application. The
> backend puts the data into a queue in order to be processed by one of a
> worker processes running on some other machine taking requests from the
> queue.
>
> The client application should be notified or take notice when the data has
> been processed and get hold of some return value.
>
> I was thinking for having some client specific 'return queue' where the
> worker could insert the return value...however the number of queues is
> limited ( by RAM?) and the number of possible clients may exceed the number
> of maximum queues....so not a solution..
>
> Is there a pattern for implementing this usecase with RabbitMQ?

As Alvaro stated, you setup a queue that's used to communicate results
from you backend to your front end.

This is a super common pattern, sometimes referred to as RPC.
Depending on the AMQP client's you're using, you should be able to
find some examples of RPC like communication over AMQP. Look around
for a tell tale "reply-to" queue property being set somewhere in code.

Short of a code example (definitely try to locate one - folks here can
help based on your language environment), it looks like this:

- Client wants to "call" a server and get a response, so sends a
message with the reply-to property set to a queue, generally one
declared specifically that call or for any response back to that
particular client
- Server (can be zero, one or more depending on the exchange and
routing rules) receives the message, does some work, notes the
reply-to queue and sends a response message via amq.direct to that
queue
- Client either polls or is otherwise notified that the a response
arrived in its reply-to queue
- Client needs to handle a "no reply" condition via a timeout

It's not uncommon for a client to block during the entire sequence,
which is probably what you want to do for a traditional web front end.

I find it helpful to think of AMQP (and any messaging scheme) as
essentially the same as email exchanges: You have a request, you send
an email message to one or more people who can help. Those people have
your reply-to address and will get back to you in due time, or not.
You impatiently check you in box for the results :)

It's definitely more work than a traditional RPC setup (SOAP, REST,
etc.) but it gives a ton more leverage over your architecture.

Garrett