Context:
We use RabbitMQ 2.8.5, and the rabbitmq-c client. We decided to upgrade to RabbitMQ 3.2.4 to take advantage of new features/stability/performance.
We don't do anything particularly complicated with RabbitMQ; the most complicated topological construct we have is an alternate exchange, and a two-node mirrored HA cluster. Everything else is standard queues and consumers.
We have some logic regarding the creation/deletion of queues that will occasionally try to delete a non-existent queue (one that has been deleted by another agent in the system). In those cases, we expect to get an AMQP channel.close
frame in response to the deletion attempt, containing 404 NOT_FOUND
or similar.
Problem:
Deletion of nonexistent queues fails as expected against RabbitMQ 2.8.5. However, when we try to delete a nonexistent queue against RabbitMQ 3.2, nothing happens. No error is received, the channel stays open, and a queue.delete.ok
frame is received.
The problem also occurs with the deletion of exchanges, bindings, etc.
Attempting to consume a nonexistent queue, however, yields the expected 404 NOT_FOUND
error.
What I've Tried:
connect(host, user, port, vhost)
channel_open(1)
queue_delete(1, "does_not_exist", ) // nowait is defaulted to 0.
connect
, tune
, and channel.open
calls, a queue.delete
went out, and a channel.close
containing the 404 NOT_FOUND error code came back near-instantly. When I ran it against the RabbitMQ 3 server, the results were surprising: a queue.delete.ok
frame was received in response, with a message-count
field set to 0. The channel remained open, with no indication that my deletion request was invalid. This was true when using the Perl client and the C client.Question:
Why is RabbitMQ 3 confirming deletes on nonexistent queues, and how can I get the old behavior (a channel closure error due to invalid operations) back?
To solve the problem, I basically did a binary search across all RabbitMQ versions between the one we were using and the latest one.
I eventually discovered that this functionality was deliberately added as part of RabbitMQ mainline enhancement 25716, in version 3.2.0.
As @zaq178miami pointed out in the comments (very informative, thanks!), the specification violations on the RabbitMQ main site were also updated at this time.
A discussion of the rationale for this is on the RabbitMQ mailing list, here.
While this behavior is more "AMQP-ish" than the previous behavior, it will require some refactoring on my part to make my existing code work with newer versions of RabbitMQ
Thanks for all the comments above. For future readers: those comments contain additional useful links regarding this issue.