Solace Guaranteed Messaging: Queues, Acknowledgements and Spooling

Solace guaranteed messaging is the delivery mode in which the Solace Event Broker stores every message on persistent storage, acknowledges the publisher only once it holds the message, and keeps it on a queue until the consumer acknowledges it back. Solace’s guaranteed messages page states that messages “accepted by the event broker through Guaranteed messaging for delivery to clients are never lost, but might not be accepted if system resource limits are exceeded”. That sentence holds the whole design: two acknowledgements, a store in between, and a limit someone has to plan.

This page walks the delivery path, the queue options and the failure handling. It belongs to the Solace messaging model in the Solace cluster.

The Solace guaranteed messaging delivery path

1. Publish. The application sends the message with persistent delivery mode. The APIs allow a number of unacknowledged messages in flight, set by the publish window session property.
2. Store and acknowledge. The broker writes the message to the spool for every matching durable endpoint and then acknowledges. Per Solace’s publisher acknowledgement page, by default it acknowledges when a third of the publish window is reached or one second has passed. If the spool quota is full, the publisher is not acknowledged, so a publisher that ignores missing acknowledgements can lose data before the broker ever had it.
3. Deliver. The broker pushes messages to the bound consumer’s flow. Messages “are delivered in the order they were published”.
4. Consumer acknowledgement. The consumer acknowledges each message, which, in Solace’s words, pulls “another message into its flow pipeline”. The APIs offer automatic acknowledgement and client acknowledgement; for anything important, acknowledge only after the work is committed.
5. Remove. Once acknowledged, the message is deleted from that queue. Other queues holding the same message are unaffected.

What it means in a plant. A batch-complete event from MES reaches ERP even if ERP is down for a two-hour patch window: the queue holds it, and ERP drains the backlog when it reconnects. The price is that both ends must be written for at-least-once delivery. A consumer that crashes after posting a goods receipt but before acknowledging will see the message again, so it needs an idempotency check such as the batch ID.

Queues, topic endpoints and access types

Solace has two endpoint types, and its endpoints page is direct about which to use: queues “are significantly more flexible than topic endpoints and are the recommended approach for most applications”. Queues hold one or more topic subscriptions, including ! exceptions, so the same published event can land in several queues, one per consuming system.

Choice	Options	Behaviour	Use it for
Durability	Durable or temporary	Durable queues survive broker restarts and are part of configuration; temporary queues last only while the client session is connected	Durable for any system of record; temporary for request-reply inboxes
Access type	Exclusive	One active consumer, others on standby; “always delivers messages in the order they are received”	Ordered streams with a hot standby, such as an ERP posting service
	Non-exclusive	Many consumers at once, served round-robin	Scaling a stateless worker pool
	Non-exclusive, partitioned	Order kept per key, load shared across consumers	Ordered per machine or order, at scale (partitioned queues)
Selectors	SQL92 filter, up to 2,000 bytes	Filters on message properties at bind time	Occasional refinement; topics are the better filter

Exclusive versus non-exclusive is an ordering decision. Round-robin across three consumers means message 2 can finish before message 1. If that breaks your logic, use exclusive access or partition by key.

Topic endpoints exist mainly for JMS durable topic subscribers. A non-durable endpoint allows only one consumer and no non-exclusive access.

When delivery fails: redelivery, TTL and dead message queues

The queues page describes how a queue gives up on a message:

• Max redelivery. Each queue has a max-redelivery setting. A message is removed when its redelivery attempts exceed it. A value of 0 means unlimited retries, which lets one malformed message (a “poison message”) cycle forever. Check what your queues are set to.
• Time to live. A message can carry a TTL, and a queue configured to respect TTL removes it when it expires.
• Dead message queue. Removed messages can go to a DMQ, by default #DEAD_MSG_QUEUE. Historically only messages published as DMQ-eligible went there. From 10.25.10, the docs state that all messages removed from the queue are sent to the endpoint’s DMQ, and 10.26.0 (the LTS as of October 2026) added endpoint-level eligibility overrides.

Set max-redelivery deliberately and watch the DMQ. A DMQ that nobody reads is a silent data-loss path with extra steps. Alert on its depth and give someone the job of draining it.

Direct messages that land on queues

If a direct (non-persistent) message matches a queue subscription, it is promoted: spooled, and from then on held until acknowledged. This lets a lightweight gateway publish direct while one consumer still gets durability. The reverse, demotion of persistent messages to a direct subscriber, gives no guarantee and can produce duplicates. The broader trade-off between the two modes is on the messaging model page.

Designing a plant flow with Solace guaranteed messaging

An illustrative example. MES publishes mfg/batch/completed/v1/{site}/{area}/{unit}/- when a batch closes. Three systems need it: ERP for goods receipt, the quality system for release, and a data platform for analytics. A workable design:

1. One durable queue per consuming system, each subscribed to mfg/batch/completed/v1/>. ERP’s outage then never delays quality release.
2. Exclusive access for ERP, with a standby instance bound. Postings stay in order and a failed instance hands over without a gap.
3. Non-exclusive access for analytics, where order does not matter and three workers share the load.
4. Max-redelivery set to a small number, such as five, with a DMQ per system so a malformed batch record is parked, alerted on and fixed rather than retried forever.
5. Idempotent consumers keyed on batch ID, so a redelivered message is recognised and skipped.
6. A quota sized for the longest planned outage, for example a weekend ERP upgrade at peak batch rate, plus margin.

The same pattern applies to production orders flowing down to a line, quality results flowing up, and genealogy records feeding traceability.

Where it gets hard

• Spool sizing. A queue fills when its consumer is down. Size the quota for the longest outage you will tolerate times the peak rate, and alert well before full. The free Standard Edition caps the spool at 800 GB and is marked not production deployable.
• Slow consumers. A queue hides a consumer that cannot keep up until the backlog is large. Monitor queue depth and age, not only connection state.
• Duplicates are normal. Failover, reconnects and redelivery all produce them. Design every consumer to be idempotent.
• MQTT QoS mapping. MQTT QoS 1 maps to guaranteed delivery, but QoS 2 is downgraded to QoS 1, per Solace’s MQTT documentation. Exactly-once is not on offer.
• HA and DR change the picture. What happens to in-flight messages on failover and under asynchronous replication is covered on high availability and disaster recovery.

Related: message replay for re-reading history after the queue has delivered it, and our IT/OT integration service for deciding which plant flows need this guarantee.