Limitations when working with RabbitMQ

Although QueueExplorer makes queues and messages look similar to folders and files, under the hood they are still first-in first-out queues. For some operations QueueExplorer will perform Receive and/or Send operations. Send operation will create new message and they’ll be put at the end of the queue.

General limitations

  • In order to display messages from a queue, QueueExplorer has to receive them from a queue, and then perform “NoAck” operation. This would set “Redelivered” flag for these messages. Also, until QueueExplorer completes reading messages, they won’t be visible to other processes. See more: Exclusive access to queues
  • If some of message headers contain complex objects like lists or dictionaries, they will be converted to strings. Thus headers will be different from original if message is edited.
  • When you load, copy, drag&drop or edit message it will go to the end of queue.
  • When you edit or copy message, QueueExplorer actually sends new messages to RabbitMQ. Because of that, some properties could be changed like routing key, source exchange, timestamp, etc.
  • Some operations could fail or produce undesirable results if messages are removed in the mean time by some other program. It’s advisable to stop other processes that use queue while operations like copy, move, etc. are performed.
  • Queue properties can’t be changed after creation. It’s a RabbitMQ limitation. Polices can be changed though, so using policies to configure queues is a workaround.

Duplicate messages

If queue contains duplicate messages, and if it’s modified after QueueExplorer loads these messages, and you perform operation which requires delete, it could happen that some messages won’t be deleted because we have no way to identify which one of the duplicates is the correct one.

Duplicate message could also mess up message selection after autorefresh, if queue was modified in the mean time.

Refreshing queue count

RabbitMQ by default updates message stats every 5 seconds. Because of that, QueueExplorer won’t immediately display correct counts on QueueList when you move/copy/delete messages if “Fast” mode is set in preferences.

Quorum queues and delivery count

Quorum queues support poison message handling. This is specific to quorum queues and not applicable to the standard ones. This mean that message that could not be delivered in specified number of tries can be automatically removed from the queue. Each message has header property x-delivery-count which gets incremented each time message delivery is attempted. Queue on the other hand has x-delivery-limit property (or delivery-limit in policy) which specifies maximum value of retries. After that, message is deadlettered or deleted. Delivery limit is optional, if it’s not specified there will be no message removals.

Delivery count and QueueExplorer

QueueExplorer reads messages and thus increments their x-delivery-limit each time messages are displayed or refreshed. Therefore simple action of displaying messages can lead to message removal from the queue! Since this is dangerous situation, QueueExplorer will warn user each time this could happen.

This could happen only when both of these conditions are fulfilled:

  • Queue is a quorum type.
  • delivery-count is specified in either queue’s properties or through a policy.