<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'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'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"><<a href="mailto:tim@rabbitmq.com" target="_blank">tim@rabbitmq.com</a>></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're using 3.0.4 - which means my advice isn'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'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>