Solace Dynamic Message Routing: How DMR Propagates Subscriptions

Solace dynamic message routing (DMR) is how Solace Event Brokers learn what each other’s clients want and forward events accordingly. Each broker advertises its clients’ topic subscriptions to its neighbours; when an event is published, it crosses a link only if someone on the far side subscribed to its topic, and only one copy crosses each link. That is what turns a set of brokers into an event mesh. This page walks through the mechanism step by step, explains why it cannot loop, and sets out where a multi-site DMR design gets hard.

It belongs to the event mesh overview in the Solace cluster.

The three building blocks of DMR

The DMR overview defines the vocabulary:

• Cluster: a group of broker nodes in which “each node … has a connection to every other node”. A cluster usually maps to one site or one cloud region.
• Internal links: the connections inside a cluster, forming a full mesh. They add capacity at one site (horizontal scaling).
• External links: the connections between clusters, made through a gateway node in each cluster. They add reach across sites and clouds (multi-site scaling).

DMR replaced Multi-Node Routing (MNR), Solace’s older linking technology, and the documentation is blunt: MNR and DMR “cannot be used at the same time. They are mutually exclusive.” A plant estate that grew up on MNR cannot mix the two during a migration.

How Solace dynamic message routing propagates subscriptions

The subscription propagation page describes two flows that run in opposite directions: subscriptions (control) travel from subscribers towards publishers, and events (data) travel back along the same path.

Step by step:

1. A client subscribes on node B2, for example to site/*/oee.
2. B2 advertises the subscription to the nodes directly connected to it in cluster B. Solace documents that the receiving nodes “don’t further propagate those subscriptions”.
3. The gateway aggregates and advertises the full subscription set of its cluster to connected clusters. Again, the receiving cluster does not re-transmit it.
4. Inside cluster A, the gateway’s interest becomes known to the other nodes, so a publisher on A1 has a path.
5. An event is published on A1 to site/plant-a/oee. It matches, so A1 sends one copy to A2, A2 sends one copy over the external link, and B1 delivers to B2.

Subscriptions are summarised before they are shared. If fifty clients on a node hold the same subscription, Solace states that only one is propagated. That keeps the control traffic proportional to the number of distinct interests, not the number of clients.

Wildcards make propagation efficient, or expensive. One subscriber to site/> in the data centre pulls every event from every site across the WAN. That is a design choice, not a bug, and it is the most common way a mesh surprises its owners. The topics and wildcards page explains how to shape a hierarchy so that the wildcards people need are narrow.

Why Solace dynamic message routing cannot loop

The forwarding rule is the same as the subscription rule. Solace’s documentation says that “only one copy of a message is sent over the internal link”, that receiving nodes “don’t transmit the data any further”, and that “since a message from a source node only traverses a single channel to get to a destination, forwarding loops never exist.”

The design consequence is direct links. Because a cluster never relays traffic for another cluster, two clusters that must exchange events need an external link between them. Solace Cloud’s Mesh Manager reflects this: it connects the DMR clusters of the event broker services in a mesh as a “full mesh”. In a self-managed estate, you build those links yourself.

DMR compared with the alternatives for linking brokers

Method	How topics are chosen	Who configures what crosses	Typical use
DMR internal links	Automatically, from live subscriptions	Nobody, once the cluster exists	Scaling one site across several nodes
DMR external links	Automatically, from live subscriptions	Nobody, once the link exists	Linking sites and clouds into a mesh
Message VPN bridge	A fixed list of topic subscriptions on the bridge	The broker administrator, per topic	A controlled crossing, such as an OT to IT boundary
MNR (legacy)	Automatically	Not for new designs; cannot coexist with DMR	Older estates only

A Message VPN bridge is the explicit alternative. It delivers only the topics configured on it, and Guaranteed messages need a bridge queue on the remote VPN. That makes it harder to change and easier to audit, which is exactly what a firewall owner between OT and IT wants. See Message VPNs and security for that pattern.

What DMR does with guaranteed messages and failures

Solace states that “DMR preserves the quality of service for the message as published.” For a plant this has a practical reading:

• Guaranteed events survive a node or link failure. Messages destined for a failed node “continue to be enqueued on its neighbouring nodes” until they can be delivered. Size the spool on the plant gateway for the longest WAN outage you plan to ride through.
• Direct events do not. A Direct event published while the path is down is lost. Line states that are republished every few seconds can be Direct; an order confirmation or a quality result should be Guaranteed. Guaranteed messaging explains the queues behind this.
• Each node should itself be highly available. DMR moves events between brokers; it does not make a single broker redundant. That is the job of an HA group, covered on high availability and disaster recovery.

Where it gets hard

• Wildcard creep. A consumer subscribed to > or site/> pulls every matching event across every link it can reach. Agree who may subscribe with broad wildcards, and enforce it with ACLs.
• Full-mesh growth. Every pair of clusters that exchanges events needs a link. Ten clusters fully meshed is 45 external links, each with firewall rules, certificates and monitoring. Decide early which plants really need to talk to each other and which only talk to the centre.
• WAN sizing from subscriptions, not from publishers. Traffic on a link is set by what the far side subscribes to. A new dashboard in the cloud can double a plant’s outbound traffic without any change at the plant. Monitor link rates, not only broker rates.
• Standard Edition caps. Solace lists DMR on the free Standard Edition as performance-capped and the edition as not production deployable. See Standard vs Enterprise.
• Mixed estates. Mesh Manager builds links for Solace Cloud Enterprise services. Self-managed brokers at plants need their own configuration process, ideally as code through the Solace Terraform providers, so that the twentieth site is built the same way as the first.
• Migrating from MNR. Because MNR and DMR are mutually exclusive, the cutover needs a plan per broker, not a gradual blend.

For how DMR behaves when brokers sit in different clouds and your own data centre, continue to hybrid and multi-cloud. If the plant WAN and firewall design is the open question, our IT/OT integration work starts there.