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 :-)