CODEWITHSUNDEEP
rabbitmqamqp
u8it
u8it

Reputation: 4296

If Channel#checkQueue (from amqplib for NodeJS) crashes channel why use?

The docs for amqplib (AMQP 0-9-1 NodeJS API) describe the functionality for Channel#checkQueue as follows...

Check whether a queue exists. This will bork the channel if the named queue doesn’t exist; if it does exist, you go through to the next round!

Assuming I understand the meaning of "bork the channel" correctly as "take down the channel", then what is this function good for? It seems very misleading to phrase it as "checkQueue" if it isn't a safe check.

Similarly, for Channel#checkExchange

Check that an exchange exists. If it doesn’t exist, the channel will be closed with an error. If it does exist, happy days.

Am I missing something or is this almost useless? I guess the channel can be recreated but not without loss of channel scoped activity.

Upvotes: 2

Views: 1008

Answers (1)

Mike Pawlowski
Mike Pawlowski

Reputation: 19

Based on my research (building a RabbitMQ client for production use), your assertion is correct: checkQueue and checkExchange are both completely useless.

  • Disclaimer: Unless your client is designed to "fail fast" or completely abort if the queue doesn't already exist as a precondition.

The established amqplib pattern is to always use assertQueue instead.

Assert a queue into existence. This operation is idempotent given identical arguments; however, it will bork the channel if the queue already exists but has different properties (values supplied in the arguments field may or may not count for borking purposes; check the borker’s, I mean broker’s, documentation).

As you can see, there are a couple of drawbacks to using assertQueue - even though it is an idempotent operation:

  1. The operation automatically creates the queue (if it doesn't already exist) rather than simply checking whether the queue exists.
    • e.g. Catch 22: Want to check if the queue already exists to determine whether you need to create the queue.
  2. The operation can potentially corrupt ("bork"... facepalm on the use of this terminology) the channel if the queue already exists and it was created using different options (compared to the current specified options)
    • e.g. exclusive, durable, autodelete, messageTtl, expires, etc.

Upvotes: 1

Related Questions