[rabbitmq-discuss] RabbitMQ sending frames after delivering connection_close_ok

[Simon MacMullen]

On 20/12/12 10:35, Marek Majkowski wrote:
> One of the Puka users found that it is possible to
> crash Puka. It happens as RabbitMQ seems to
> keep on sending frames after connection_close_ok.
>
> Puka has trouble behaving in such a case.

Yes, I've managed to replicate this. However, I would point out that 
Puka's behaviour in this case is rather odd, so I think some fault lies 
with both sides. Certainly RabbitMQ should not let itself be provoked 
into doing this though, so I'll file a bug.

Looking at the situation with Wireshark, we see the following sequence 
of events. Channel numbers in brackets.

We have opened the connection and two channels, set confirm mode and 
published a message on (1) and declared a queue on (2). Then things get odd:

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

And now RabbitMQ sends connection.close-ok followed by channel.open-ok. 
That channel.open-ok is... unhelpful at best.

> Is it a valid AMQP behaviour?

Good question. The spec is quite vague on this - it only says "This 
method [connection.close-ok] confirms a Connection.Close method and 
tells the recipient that it is safe to release resources
for the connection and close the socket." It does not say that nothing 
else should be sent!

So I am not sure we are outside the *letter* of the spec. But this 
behaviour is clearly confusing so we will change it.

But you should think about whether Puka should be sending normal methods 
after connection.close too :-)

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware