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 in 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.

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.