<div dir="ltr">Matthias,<div><br></div><div>� � Thanks for the reply, I'll forward it on to the rest of my team. �We'll implement the workaround ASAP.</div><div><br></div><div>� � In the mean time, is there anything I/we can do to help resolve this issue?</div>
<div><br></div><div>Morgan Nelson<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 21, 2013 at 5:33 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Morgan,<div class="im"><br>
<br>
On 21/06/13 18:44, Morgan Nelson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
� � �I'm having a crash in RabbitMQ about every 36 hours or so. �I have<br>
a gist at <a href="https://gist.github.com/korishev/5832748" target="_blank">https://gist.github.com/<u></u>korishev/5832748</a> with a (very large)<br>
set of crash and supervisor reports.<br>
</blockquote>
<br></div>
That's a bug. It's quite difficult to trigger, so I'm not surprised it's taking a while for your broker to run into it.<br>
<br>
AFAICT the bug will only surface on a channel with basic.qos prefetch, when there is a sequence of several basic.consume and basic.cancel commands involving the same queue. And there are several other conditions that need to be met, and the timing needs to be just right.<br>
<br>
A workaround until we fix this would be closing channels after basic.cancel and using a fresh channel for every basic.consume.<br>
<br>
Thanks for reporting this!<br>
<br>
Regards,<br>
<br>
Matthias.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Morgan Nelson<br>Software Acolyte<br><span><span id="gc-number-0" class="gc-cs-link" title="Call with Google Voice">(214) 392-6483</span>
</span></div></div></div>