Queues & messages

Queues are browsed per vhost: select one on the overview and its queue list opens. Every operation on this page runs as the connection's account, over AMQP or the management API depending on the operation; the table at the end maps which is which.

The queue list

Each row shows the queue's type and state, its ready, unacked, and total message counts, its consumer count, and a publish-rate sparkline. The list polls while open and pages at 200 queues.

The name filter is applied by the broker, so it narrows the whole vhost rather than the loaded page. The chips above the list cut it down by state:

Group by service folds each queue together with its _error and _skipped siblings under their shared base name, following the MassTransit endpoint naming convention. Queues that fit no service group collect in an ungrouped section at the end.

Inside a queue

A queue opens on three tabs: overview, messages, and bindings.

The overview pairs the live stats (ready, unacked, consumers, memory) with charts of queued messages and publish and deliver rates over the last ten minutes. The definition panel beside them shows the queue type, durability, effective policy, delivery limit, and dead-letter exchange; a quorum queue also lists its members and marks the leader. RabbitMQ 4.0 and later give quorum queues a delivery limit of 20 when nothing sets one, and Redrive shows that inferred default rather than leaving the field blank.

The bindings tab lists the exchanges bound to the queue. Adding a binding takes a source exchange and a routing key; removing one asks for confirmation. Both changes go through the management API and need write on the queue and read on the exchange.

Peeking messages

Peek, on the messages tab, copies messages from the head of the queue and puts them straight back. Redrive fetches each message with basic.get without acknowledging it, then returns the whole batch in one requeueing basic.nack. Nothing is consumed, and the messages reappear on the queue flagged redelivered.

The result is a snapshot, not a live tail. Peek competes with the queue's consumers, so it can return fewer messages than requested, and redelivery can reorder them. A peek reads up to 100 messages (50 by default) and stops early once it holds 16 MB of bodies, marking the snapshot truncated; the list notes how many messages remain behind it. Stream queues cannot be peeked, because basic.get does not apply to streams.

Peeking a quorum queue on RabbitMQ older than 4.3 spends delivery-limit headroom. Those brokers count a requeue as a failed delivery, so each peek raises every returned message's x-delivery-count, and a message that reaches the limit is dropped or dead-lettered. Redrive asks for confirmation before peeking such a queue and flags any message with three or fewer peeks left. From 4.3 on, the explicit basic.nack return costs no headroom and the confirmation disappears.

Select a message to inspect it. JSON bodies are pretty-printed with a collapsible tree view; other bodies show as raw text, or base64 when they are binary. Beside the body sit the delivery details (exchange, routing key, delivery count), the AMQP properties, and the headers. Download saves the body bytes exactly as they came off the queue.

MassTransit messages get a parsed view. Redrive detects the envelope by its application/vnd.masstransit+json content type, or by body shape, and shows the message identifiers, source and destination addresses, sent time, message types, and producing host. On a message that failed, the MT-Fault-* headers become a fault panel: exception type and message, stack trace, fault timestamp, the consumer and machine that failed, and the retry and redelivery counts.

Purge and delete

Purge drops every ready message in the queue with one AMQP queue.purge call. Deliveries a consumer holds unacknowledged survive it. The account needs read on the queue, and every purge is recorded in the action log, Redrive's own record of every redrive, discard, purge, and delete it has run.

Delete removes the queue itself, messages and bindings included, through the management API. It needs configure on the queue and is recorded in the action log too. Both operations ask for confirmation first.

Protocols per operation

Both protocols authenticate with the connection's account; what differs is the permission set an operation exercises and which of the two connection probes has to be healthy. Message operations need AMQP: while only the management API is reachable, Redrive keeps browsing but disables peek, redrive, discard, purge, and publish.

Which permission each operation needs is listed in Getting started. Publish is described in Publishing & topology.

Next

Continue to Redriving to move messages back to their source queues.