Publishing & topology

The publish form sends a raw test message; the exchange pages and the topology graph show where it would go. Everything here runs as the connection's account, and which operations travel over which protocol is mapped in Queues & messages.

Publishing a message

Publish sends one message over AMQP with basic.publish. The target is either an exchange with a routing key, or a queue: queue mode publishes through the default exchange with the queue name as the routing key, which reaches that queue directly. Opening the form from an exchange's page preselects that exchange.

The body reaches the broker as raw UTF-8 bytes, exactly as typed. The editor flags JSON syntax errors but does not block publishing, and the content type is a label on the message, not a format check.

Redrive publishes with the mandatory flag and waits for the broker's confirm, so the form reports where the message ended up. Routed means the broker confirmed delivery to at least one queue. Unroutable means nothing is bound for that exchange and routing key; the broker returned the message and nothing was delivered.

Publishing needs write on the exchange and a healthy AMQP probe; while only the management API is reachable, the form is disabled. The permission table is in Getting started.

Exchanges and bindings

The exchange list shows each exchange's type, its features (durable, auto-delete, internal), and its publish-in and publish-out rates. The name filter is applied by the broker, the list polls while open, and it pages at 200 exchanges. The default exchange appears as (AMQP default) but has no page of its own.

An exchange opens on its publish rates over the last ten minutes, beside its definition: type, durability, auto-delete and internal flags, effective policy, and arguments. Publish to this exchange jumps to the publish form with the exchange preselected.

The bindings tab lists bindings in both directions: with this exchange as the source, or as the destination of an exchange-to-exchange binding. The list is read-only here. Bindings are added and removed on the bindings tab of the queue they target, described in Queues & messages; both changes go through the management API and need write on the queue and read on the exchange.

Bindings from the default exchange are implicit (every queue is bound to it under its own name), so Redrive refuses to create or remove them.

The topology graph

Topology draws the whole vhost: exchanges and queues as nodes, bindings as edges. Parallel bindings between the same pair collapse into one edge that carries all their routing keys. The data is three management API reads (the vhost's exchange, queue, and binding lists), and the graph is read-only: nothing on the canvas writes to the broker, so a read-only account can use it.

Two toggles shape the view. System reveals the default exchange and the amq.* exchanges, hidden by default with a count of what is hidden. The MassTransit lens, on by default, folds each service's queues and their endpoint exchanges into one cluster under the service name, and flags the cluster when its error queue holds messages. Message-type exchanges, the ones with a : in their name, stay outside the clusters.

Search dims everything but the matches and their direct neighbors; selecting a node focuses its neighborhood the same way. The selection panel shows the node's type and binding counts, message and consumer counts for a queue, and a link to its full page.

A vhost past 500 nodes renders search-first. The full graph would be unreadable at that size, so the canvas stays empty until you search, then draws the matches and their direct neighbors.

The graph polls at the same interval as the lists.

Next

Continue to Configuration for the flags and environment variables Redrive reads.