[rabbitmq-discuss] Non-blocking Consumers approach

Mon Aug 27 13:37:19 BST 2012

Thanks Tim,

I read the API guide and still stuck to the QueuingConsumer, for each
incoming message I create a new service thread (with common channel,
without that the service won't know which message to acknowledge). But in
the guide, it is mentioned that the channel should be created for each
thread. Now, my question is does this guide assumes that we run different
consumer threads? *I can't understand the concept of different consumer
threads*. I run a single consumer and use basicConsume() to listen to the
messages and each message (nextDelivery()) will give rise to a new service
thread. Again, each message creating a thread is scary !

If it helps, I am running the consumer as a java application and use
basicConsume() and nextDelivery() in a while loop to process the messages.
Our application sends messages to these non-stop. So, I am looking for a
consumer which will not block the incoming messages when it is processing a
large message.

-Mahesh

On Mon, Aug 27, 2012 at 2:47 PM, Tim Watson <tim at rabbitmq.com> wrote:
> Hi Mahesh,
>
> On 27 Aug 2012, at 08:58, Mahesh Viraktamath wrote:
>
>> Hi,
>>
>> We used RabbitMQ to implement a simple producer-consumer architecture.
>> It was fine until very recently, when we encountered the blocking
>> calls. I ran two nodes in a cluster; in cases where the consumer took
>> more than the usual time and all subsequent messages kept on waiting.
>> Then, I came to know that I used QueuingConsumer which is a blocking
>> architecture, now I know I have to use my own implementation of the
>> DefaultConsumer. But, I am clueless as to whether I should manage the
>> threading model or the RabbitMQ itself has any provision on that.
>> Another thing that is confusing is, whether we run different type of
>> consumers (with different duties) separately or we maintain a single
>> main class which will start consumers as the messages come in.
>>
>
> Have you read the API guide (http://www.rabbitmq.com/api-guide.html) for
details about threading and using your own executor service? That's
probably a good place to start. The latter question (about choosing how to
structure your code) is really something you'll have to decide yourself,
based on the responsibilities of each class and whether or not and to what
extent separation makes sense in the design.
>
> Cheers,
> Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120827/74953d1a/attachment.htm>