Solace Message Replay: How the Replay Log Works and When to Use It

Solace message replay lets the Solace Event Broker keep a record of guaranteed messages in a replay log and send them again, in their original order, to a queue or topic endpoint that needs them. Solace’s replay documentation lists the typical reasons: recovering an application that corrupted its data, correcting a topic-to-queue mapping that was set up wrong, giving a late-joining application the history it missed, and event sourcing or on-demand analytics. A replay can start from the oldest message held, from a date and time, or after a specific message ID, and the consumer then continues with live messages without any change on its side.

This page explains the mechanism, the use cases and the limits. It belongs to the Solace messaging model in the Solace cluster.

How Solace message replay works

The log. Each Message VPN can have a replay log. By default it stores all guaranteed messages, and administrators can apply topic filters, “including wildcard subscriptions and topic exceptions”, to log only what is worth keeping. It is meant for guaranteed messages; per the docs, “Direct messages can be logged only by promoting them”.

Retention is a size quota. The log has a max-spool-usage in megabytes. “Messages are retained in the replay log until its spool usage reaches 90% of its configured quota, after which the oldest messages are removed.”

Who starts it. “Message replay can be initiated from an event broker management interface or from a client application using the Solace Messaging APIs”, and it works for any consumer protocol, “including AMQP, MQTT, REST/WebHooks, and Solace Messaging APIs”.

What happens to the endpoint. The playback documentation is precise:

1. “All messages stored on an endpoint are deleted prior to replay, and bound flows are unbound.” The Solace APIs rebind automatically.
2. Messages from the log are delivered from the chosen start point.
3. Live messages for that endpoint are not spooled to it directly; they go into the replay log and “are replayed to the endpoint when the replay catches up to them”.
4. If the requested date is earlier than the log’s creation date, “the replay fails and the replay state of the endpoint is set to failed”.

Use cases for Solace message replay in a plant

Situation	Start point	What replay gives you
A new consumer, such as a quality analytics service, goes live	From oldest, or a date	The history it missed, then the live stream, through one queue
A consumer wrote bad data after a faulty deployment	After the last good message ID, or the deployment time	A clean re-run of everything after the fault
A queue subscription was missing a topic for two days	From the date the mistake was made	The messages that never reached the queue
Rebuilding a read model or a cache	From oldest	State rebuilt from events, the event sourcing idea

An illustrative case. An MES integration release on Tuesday mis-mapped scrap reasons, and the error is found on Thursday. The team fixes the code, deletes the bad records, and replays the integration’s queue from Tuesday’s deployment time. Two days of scrap events flow through again, then the queue continues with live data. Without replay, the alternatives are asking every line to re-enter data or writing a one-off reconciliation against the historian.

Sizing Solace message replay retention

Because retention is by size, convert it to time before relying on it:

1. Measure the logged traffic. Peak messages per second multiplied by average size, for only the topics the log filters in.
2. Choose the recovery window. How long could a bad deployment go unnoticed? For many plants, a long weekend plus a day is a realistic answer.
3. Calculate the quota. Rate times size times window, then divide by 0.9, because trimming starts at 90%.
4. Check the spool budget. The log shares the broker’s spool with queues. The free Standard Edition caps the spool at 800 GB and is marked not production deployable; Enterprise Edition goes to 6 TB per the edition table.
5. Filter aggressively. High-rate live values that a historian already keeps rarely belong in the replay log.

Replay is not an archive. For months of history, a historian, a data lake or a streaming log is the better home. The difference between a broker’s replay log and a streaming platform’s retained log is covered on Solace vs Kafka.

Solace message replay compared with other ways to re-read history

Replay is one of several places a plant can recover past events from. They differ in who controls the rewind and how far back it goes.

Option	Who rewinds	How far back	Best for
Solace replay log	An administrator or the client, per endpoint, on request	As far as the size quota allows	Recovery after a fault, late joiners, fixing a missed subscription
Streaming log (Kafka and similar)	Each consumer group, by moving its offset	Per-topic retention, often days to forever	Analytics, many independent re-reads, stream processing
Historian	A query against stored values	Years	Process values and trends, not business events
Source system re-export	The owning team, by hand	Whatever the source kept	Last resort; slow and often incomplete

In our view the options combine rather than compete. Many architectures keep the broker’s replay log short, a few days sized for operational recovery, and send the same events to a streaming platform or lake for long retention. The broker then handles the “a consumer broke on Tuesday” case quickly and locally, while the analytics team re-reads months of history without touching production queues. The Kafka vs MQTT guide explains the plant-edge, streaming-core pattern this fits into, and our article on keeping data local in manufacturing covers why the short, on-site copy still matters.

Where it gets hard

• Partitioned queues cannot be replayed. The docs state it twice. If you need ordered scale-out and replay, see partitioned and last value queues and plan a separate recovery path.
• Replay and replication do not combine. Solace states “Replication with message replay isn’t supported”, because messages logged at the active site may not reach the standby site’s log. Factor that into the HA and DR design.
• Message IDs are local. In an event mesh, “a given message is assigned a different replication group message ID in each replication group”, so an ID from one broker is meaningless on another.
• Replay empties the queue. Anything waiting is deleted first. Let the consumer drain, or accept that those messages will come back from the log.
• Duplicates. Replaying from a time rather than an exact ID will usually resend messages already processed. Consumers must be idempotent, as on any guaranteed flow described in queues and guaranteed messaging.
• Selectors. Solace advises against replaying to an exclusive queue whose active consumer uses an egress selector.

Back to the messaging model or the Solace hub.