[rabbitmq-discuss] RabbitMQ .NET Client. Questions about QueueingBasicConsumer

[Mike Hadlow]

Hi All,

I'm writing a high-level "opinionated" .NET API on top of the supplied RabbitMQ .NET client that I've named EasyNetQ. It's on GitHub here:

https://github.com/mikehadlow/EasyNetQ

Currently I'm using the QueueingBasicConsumer and spinning up a single thread that sits in a loop doing SharedQueue.Dequeue(), see the code here:

https://github.com/mikehadlow/EasyNetQ/blob/master/EasyNetQ/QueueingConsumerFactory.cs

My question is about the scenario where messages are being pushed onto the queue by QueueingBasicConsumer faster than my client callbacks can handle them. Surely messages will build up in the SharedQueue until we run out of memory, crash, and lose all the queued messages? It would be much better if messages were pulled from RabbitMQ only as fast as the consumers can process them.

Does anyone have any experience with this scenario? What is the recommended subscription pattern? Should I be using BasicGet instead?

Many thanks
Mike

15below Limited: Company registered in England and Wales No 3945289
Registered Office: Lyndean House, 43-46 Queens Road, Brighton BN1 3XB, United Kingdom

15below Australia Pty Limited: ABN 25 132 716 379
Level 50, 120 Collins Street, Melbourne, Victoria 3000, Australia

Please think about the environment before printing this email.

************************************************************************
This email and any attachments may be confidential and/or legally privileged and are solely for the use of the intended recipient. If you have received this email in error please contact the sender. Any views or opinions expressed within this e-mail are solely those of the sender, and do not necessarily represent those of 15below unless otherwise specifically stated. Although 15below has taken every reasonable precaution to ensure that any attachment to this e-mail has been checked for viruses, it is strongly recommended that you carry out your own virus check before opening any attachment, as we cannot accept liability for any damage sustained as a result of software virus infection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110707/80f5273d/attachment.htm>