<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">> (Bear in mind that the channel is not damaged by this, you don't have to close it if you don't want to. But I can see you might want to.)</span><br>
<div><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></div><div style><font face="arial, sans-serif">The decision to close the channel is for symmetry with the "consume" method, which closes the channel if it fails.</font></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 1, 2013 at 3:40 PM, Chip Salzenberg <span dir="ltr"><<a href="mailto:rev.chip@gmail.com" target="_blank">rev.chip@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I am using a modified AnyEvent::RabbitMQ Perl module (the standard one does not advertise its willingness to receive channel cancellations). �The module is event-driven; its input handler is not dependent on application logic, and is where I'm getting my frame dumps; and the module continues to send heartbeat frames even after other events stop. �Also, as an experiment, I arranged to send a CancelOk and got an error response (which was printed correctly). �So I do not believe the client is "hanging" in any sense.<div>
<br></div><div>Does the Java automated test of close-after-cancel-notification expect a CloseOk? �Does it get one?</div><div><br></div><div>How do you suggest dumping the frame traffic without depending on the suspect client module?</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 1, 2013 at 4:06 AM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@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>On 01/05/13 05:16, Chip Salzenberg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've successfully used the optional server feature of sending a<br>
basic.cancel when a consumed queue is deleted. �Great. �But a reasonable<br>
thing to do at that point is to close the channel, right? �But when I<br>
send a channel.close in that circumstance, RMQ 3.0.4 does not send a<br>
close-ok. �It doesn't send anything. �This makes my app hang. �I have to<br>
cheat and ass_u_me that the channel is closed in order to keep working.<br>
</blockquote>
<br></div>
Well that definitely sounds wrong.<br>
<br>
(Bear in mind that the channel is not damaged by this, you don't have to close it if you don't want to. But I can see you might want to.)<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am I doing something wrong? �Is this a server bug? �Both? �:)<br>
</blockquote>
<br></div>
I doubt it's a server bug; we have an automated test which closes a channel after receiving a cancel notification. But Steve points out the way in which the Java client could trip you up. In previous mails I think you mentioned using the Perl client; possibly it has a similar limitation in callbacks?<br>
<br>
If not, please post some example code and I will look into it.<br>
<br>
Cheers, Simon<span><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>