[rabbitmq-discuss] RabbitMQ sending frames after delivering connection_close_ok

[Marek Majkowski]

On Thu, Dec 20, 2012 at 12:13 PM, Simon MacMullen <simon at rabbitmq.com> wrote:
> Puka -> RabbitMQ (2) basic.qos
> Puka -> RabbitMQ (3) channel.open
> Puka -> RabbitMQ (0) connection.close
>
> Up until this point Puka is behaving oddly (not waiting for the qos-ok or
> open-ok before issuing connection.close) but I don't think it's violated the
> spec. But then:
>
> Puka <- RabbitMQ (2) basic.qos-ok
> Puka -> RabbitMQ (2) basic.consume
>
> Puka has now sent basic.consume after connection.close!
>
> Puka <- RabbitMQ (0) connection.close-ok
> Puka <- RabbitMQ (3) channel.open-ok

Simon, thanks for the great investigation!

Internally for puka everything is async, everything continues unchanged
until connection.close.ok is received. Only then puka cleans up.

Obviously issuing basic.consume after sending connection.close
makes little sense from protocol perspective, but it's completely
valid from puka point of view - user just issued connection.close
and did some further actions before waiting for the result.

I think my quick workaround will be to just ignore everything rabbit
sends after receiving connection.close.ok.

Thanks for fixing that on the server side :)

Cheers,
    Marek