STOMP connection not closed after emitting ERROR frame

[eigengrau]

As per the STOMP spec, a broker must always close the connection after sending an ERROR frame to a client. However, when using the STOMP and Web STOMP plugins, RabbitMQ sometimes (always?) leaves the connection open. Since clients rely on the assumption that the connection will be closed after any error, they will generally not attempt to renew their subscriptions after encountering an ERROR frame without a subsequent disconnect, resulting in messages not being received.

Steps to reproduce

1. Connect to a single-node RabbitMQ system
2. Subscribe to a queue /queue/foo via STOMP
3. Delete that queue using rabbitmqctl
4. Observe that the client has received an ERROR frame with a notification that its subscription was cancelled
5. Observe that the client’s connection to the broker is still alive. If any additional subscriptions were made in step 1, the client will still receive messages for these.

We also observe this behavior in a clustered configuration. A client connected to RabbitMQ node A and subscribed to a queue residing on RabbitMQ node B, when node B receives a SIGTERM, the client will also be sent an ERROR frame, but its connection to node A still remains open.

RabbitMQ version

RabbitMQ version: 3.8.4

Erlang configuration: Erlang/OTP 23 [erts-11.0] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:64] [hipe]

Enabled plugins:

• rabbitmq_web_stomp
• rabbitmq_stomp
• rabbitmq_management
• amqp_client
• rabbitmq_web_dispatch
• cowboy
• cowlib
• rabbitmq_management_agent

[michaelklishin]

This works as expected. Deletion of a queue results in a consumer notification. It is not a reason to close the connection: RabbitMQ distinguish between the two. This is different from, say, an unparseable frame, an unsupported or “unusable” or “unavailable” destination, and other errors that are unrecoverable.

[michaelklishin]

Here's the relevant STOMP spec section: http://stomp.github.io/stomp-specification-1.2.html#ERROR. We are not aware of clients depending on this behavior (at least this is the first report in years that I have seen) and not every error is fatal but we can convert consumer cancellation notifications into such unrecoverable errors. This would be counter-productive IMO but at least it can be considered.

[michaelklishin]

Filed https://github.com/rabbitmq/rabbitmq-stomp/issues/150 which also discusses a couple of alternatives for “soft errors” and arrives at a conclusion that they are not viable. So in STOMP, a server can only general a “fatal error”. That’s pretty unfortunate.