[rabbitmq-discuss] 2.4.0 channel and connection close behavior

[Matthew Sackman]

On Wed, Mar 30, 2011 at 02:34:24PM -0400, Aaron Westendorf wrote:
> In 2.3.0 and prior, I could send the connection close even if there
> were pending channel closures, but in 2.4.0, if I send a channel close
> followed immediately by a connection close, I stop receiving frames
> altogether.  This occurred with one channel (beyond 0) and 500
> channels.  I didn't enable heartbeats so perhaps frame processing was
> still alive but I simply never received a close_ok on the channel or
> connection.
> 
> I assume that this is a bug but could easily be a stricter
> interpretation of the spec.

I think it's a different interpretation of the spec. Certainly we
changed some code in those areas to solve another genuine bug, where a
close_oks were not being sent (the issue is: if both a client and the
server send channel.close (or connection.close) to each other at the
same time (they pass in mid-air), _both_ client and server should reply
with (channel|connection).close_ok.

Now in the course of fixing that, we may have changed behaviour
elsewhere, but I believe that the spec is silent as to what should
happen if the client sends channel.close and then immediately follows
that with connection.close. The only guarantee you'll have is that you
should get back the connection.close_ok. I don't believe the spec says
that the connection.close_ok should be delayed until all pending channel
closes complete - after all, why special case the channel.close? - no
other methods are waited upon when a connection.close occurs.

However, from your description above, it sounds like you're not even
getting the connection.close_ok back. Is that really the case?

Matthew