[rabbitmq-discuss] "Returning" values

Mon Mar 29 17:46:50 BST 2010

You can use a single reply queue for a caller - use the correlation ID
property to associate a response from a server with a particular call.
The server will need to pass the request correlation ID to the
response and you'll know who it came from.

Also, rabbit cleans up auto deleted reply queues very nicely, so you
really only need queues for running calls. But I prefer using
correlation IDs in any case.

Garrett

On Mon, Mar 29, 2010 at 10:39 AM, Andreas Jung <lists at zopyx.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> First, I know about the explained concepts very well.
>
> The main question is: assuming you have 10k visitors on a portal and
> each visitor would need a queue...you might run out of resources (I was
> able to create 16k queues at a time before I got errors). So this
> approach does not scale very well. Of course you can create individual
> queues for each client on request and as needed...no idea about the
> overhead for creating and destroying queues...
>
> Andreas
>
> Garrett Smith wrote:
>> 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
>
>
> - --
> ZOPYX Limited              \ zopyx group
> Charlottenstr. 37/1         \ The full-service network for your
> D-72070 Tübingen             \ Python, Zope and Plone projects
> www.zopyx.com, info at zopyx.com \ www.zopyxgroup.com
> - ------------------------------------------------------------------------
> E-Publishing, Python, Zope & Plone development, Consulting
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuwycIACgkQCJIWIbr9KYwnOgCfXMPiVL6aXX06M1jWQVO96hbx
> EUYAnjek2cPw5y9kIc/gOnVp8kqF4Tj6
> =NAU8
> -----END PGP SIGNATURE-----
>