<div dir="ltr">Yes, the solution is appropriate for avoiding the connection blocking. In our case, the consumer itself hangs and the client waits for the ack and the connection goes idle. We need to close such connections where the ack is delayed from the consumer side.<div>
<br></div><div><br></div><div>Thanks again,</div><div>Mahesh</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 1:41 PM, Michael Klishin <span dir="ltr"><<a href="mailto:mklishin@gopivotal.com" target="_blank">mklishin@gopivotal.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mahesh Viraktamath:<br>
<div class="im"><br>
> Is there any timeout mechanism for connections to close after a fixed time duration, so that such connections do not block rabbitmq.<br>
<br>
</div>Have you tried using shorter heartbeat intervals? Also, unless you run out of file descriptors<br>
available to RabbitMQ, consumer connections should not block anything. But even in that<br>
case increasing max # of file descriptors (ulimit -n) is a much better solution.<br>
--<br>
MK<br>
<br>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br></div>