[rabbitmq-discuss] "Returning" values

Mon Mar 29 16:39:46 BST 2010

-----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-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100329/754df2d8/attachment.vcf 