Thanks Tim,<br><br>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? <b>I can't understand the concept of different consumer threads</b>. 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 !<div>
<br></div><div>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.<br>
<br><br><br>-Mahesh<br><br>On Mon, Aug 27, 2012 at 2:47 PM, Tim Watson <<a href="mailto:tim@rabbitmq.com">tim@rabbitmq.com</a>> wrote:<br>> Hi Mahesh,<br>><br>> On 27 Aug 2012, at 08:58, Mahesh Viraktamath wrote:<br>
><br>>> Hi,<br>>><br>>> We used RabbitMQ to implement a simple producer-consumer architecture.<br>>> It was fine until very recently, when we encountered the blocking<br>>> calls. I ran two nodes in a cluster; in cases where the consumer took<br>
>> more than the usual time and all subsequent messages kept on waiting.<br>>> Then, I came to know that I used QueuingConsumer which is a blocking<br>>> architecture, now I know I have to use my own implementation of the<br>
>> DefaultConsumer. But, I am clueless as to whether I should manage the<br>>> threading model or the RabbitMQ itself has any provision on that.<br>>> Another thing that is confusing is, whether we run different type of<br>
>> consumers (with different duties) separately or we maintain a single<br>>> main class which will start consumers as the messages come in.<br>>><br>><br>> Have you read the API guide (<a href="http://www.rabbitmq.com/api-guide.html">http://www.rabbitmq.com/api-guide.html</a>) 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.<br>
><br>> Cheers,<br>> Tim<br><br></div>