<div dir="ltr">Hello Tim,<div><br></div><div style>Thanks for the answer! I am skeptical this is due to a network event (I am running this test extremely isolated on a local VM) and rather think it&#39;s due to some interactions with the client code.<span id="dbph-1"></span></div>
<div style><br></div><div style>I should have clarified that I am running pika 0.9 with a SelectConnection. I build a custom library on top of that to deal with my cluster configuration but the bottom line that I think it&#39;s problematic is that I am handling the processing of the message straight on the IOLoop thread. This, as you hinted, prevents pika from handling/sending heartbeats properly. I can fix this in two ways:</div>
<div style><br></div><div style>1) move the actual processing to a separate thread and let the ioloop go unstuck. While this is obviously the more straightforward fix, it involves actually a few changes to my curent structure that I am trying to punt on</div>
<div style>2) increase the heartbeat timeout.</div><div style><br></div><div style>For option 2), what is the internal timeout set in Rabbit? Can I increase it from the client on a per channel basis?</div><div style><br></div>
<div style>Best, Pier<span id="dbph-1"></span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 22, 2013 at 4:24 AM, Tim Watson <span dir="ltr">&lt;<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 03/22/2013 10:54 AM, Tim Watson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Pierpaolo!<br>
<br>
On 03/22/2013 08:11 AM, Tim Watson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the channel is disappearing (because rabbit considers the connection to have dropped) then I would suggest configuring heartbeats in your client too ensure the connection stays alive.<br>
</blockquote>
<br>
Someone just kindly pointed out that you&#39;re using 3.0.4 - which means my advice isn&#39;t all that helpful as the server will negotiate heartbeats with the client by default (and pika has support for heartbeats). So my suspicion, is that if un-acked messages are disappearing and the client has not rejected them, that the connection must have been<br>

disrupted somehow (network failure, packet loss, ?) causing the broker to re-queue them, or the consumer must have crashed or a channel error generated. Is there anything in the logs to indicate what might be happening?<br>

<br>
</blockquote>
<br></div>
In fact, depending on how you&#39;re interacting with the broker, that heartbeat might not get handled by pika and the broker will disconnect you anyway. Are you using BlockingConnection by any chance?<div class="HOEnZb">
<div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Tim<br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</div></div></blockquote></div><br></div>