Diverts

Updated 6 October 2026 · applies to 1.0.1 · Commercial

A divert is a broker-side rule that sends a message somewhere other than where it was addressed. It is configuration, not traffic: nothing about it changes because a message arrived.

One column carries the whole meaning, and it is not the name

Effect is either moves or copies, and the difference is total:

moves (exclusive) — the message goes to the forwarding address, and the queues bound to the source address never see it.
copies (not exclusive) — both receive it.

One setting, opposite outcomes. The failure it produces is a queue that silently stops receiving, so the column is shown as those two words rather than as a tick against the word "exclusive" — which tells a reader nothing about what happens to the queues on the source address, and that is the only thing the column is for.

Each one names the two addresses in its tooltip, so the sentence is complete without going anywhere else.

The rest of the row: the divert's name with its routing name beneath it, the route itself as source → forwarding, and the filter it applies (or everything). Two more columns are off by default and turned on from Columns: Routed as, the routing type it forwards as, and Transformer — the class that rewrites a message on the way through, or none. A divert the broker created as part of a retroactive address is marked internal.

The Diverts list: two rules, one that copies and one that moves, each with its route and the filter it applies. — One divert **copies** and one **moves**, and the two words are the whole difference. Beside them: the route and the filter each applies — the `tenant-acme` divert moves only what matches `tenant = 'acme'`.

One divert **copies** and one **moves**, and the two words are the whole difference. Beside them: the route and the filter each applies — the `tenant-acme` divert moves only what matches `tenant = 'acme'`.

Editing is a smaller form than creating, and that is the broker's doing

New divert takes a name, the source address, the forwarding address, the effect, a filter, the routing type and an optional routing name — blank uses the divert's own name.

Editing takes fewer fields. Artemis's update operation accepts the forwarding address, the filter and the routing type — and nothing else. It does not take the source address or the exclusivity, and a divert has no other operations at all.

So changing either of those means destroying the divert and creating it again. That is a different act with a different blast radius, and the dialog says so rather than offering a field that would quietly do nothing.

Choosing "moves" while creating one raises a warning where the choice is made, naming the source address: the queues bound to it will stop receiving whatever this divert matches — and nothing about those queues changes, and nothing on their own screen will say why. That is the failure this column exists to prevent, said at the moment it can still be avoided.

The routing type has a third option here

Beyond ANYCAST (shared across the queues at the destination) and MULTICAST (copied to each), a divert can be set to PASS — keep the routing type the message arrived with.

Every create and update is read back, because the broker lies about this one

Artemis answers 200 for a divert it did not create.

Its createDivert builds a configuration by looping over the keys it was given and ignoring any it does not recognise, then hands the result to the deploy step — which logs "Must specify a forwarding address for each divert. This one will not be deployed" and returns. Nothing propagates. The management call succeeds, the operator is told it worked, and no divert exists.

So BROKA reads the divert back after every create and every update. If it is not there, you are told it was refused and pointed at the broker's log, rather than congratulated.

The list arrives whole

Artemis has no paged view for diverts; it exposes them as MBeans found by pattern, so the list arrives whole. The pager under it is the console's own: the whole list is sorted before it is paged, so a header click orders every divert, not just the page in view.

Deleting a divert

Delete on the row is confirmed, asks for a reason, and says what changes. For a divert that moves, what is routed to the source address starts reaching the queues bound there again — which may be queues that have not received anything for a long time. For one that copies, only the copy stops.

The Delete divert payments-audit? confirmation over the Diverts list: The copy sent to payments.audit stops. payments keeps receiving exactly as it does now. Below it a Reason field reading The audit copy moved to the mirror — CHG-2320, the note that the change is recorded with that reason on the audit entry, and Cancel beside Delete divert. — For a divert that copies, the confirmation says only the copy stops and the source address carries on as it is.

For a divert that copies, the confirmation says only the copy stops and the source address carries on as it is.

Writes

New divert, Edit and Delete appear only for someone allowed to change this broker, and not in a read-only environment or on a read-only connection; there the page says why instead. Each is recorded in the audit trail.

While a data masking rule masks anything on an address or a queue for you, creating or editing a divert is refused, and the refusal names the rule: a divert copies or moves messages to wherever it forwards them, and the rule does not follow. BROKA does not try to work out which messages a divert would reach — a fully qualified name or a routing-type prefix is read one way here and another by the broker — so any such rule is enough. Someone who may read those messages unmasked is not refused; deleting a divert never is.