Message Delivery Modes
- At most once delivery
- At least once delivery
- Transacted delivery
Direct messaging is meant for use with high-speed applications that can tolerate occasional message loss. Producers can publish messages to a topic, and when these messages are received by the event broker, they are delivered to Consumers with matching topic subscriptions. Direct messages are neither spooled on the event broker - in other words, they're not persisted - for consuming clients nor acknowledged when received.
Persistent, or Guaranteed, messaging is a combination of: sending Persistent messages with proper publication confirmation handling, and at least once delivery. And, equally important, Guaranteed messages are never lost. There are two aspects to Guaranteed messaging: Publishing Guaranteed Messages and Receiving Guaranteed Messages.
Clients can publish to either a queue or topic when Persistent messaging is used to send messages to an event broker.
When the messages are received by the event broker, they are saved in the event broker's message spool - that is, they're persisted - before they're acknowledged back to the producers. The acknowledgment is confirmation to the publisher that the event broker accepted the message and it won't be lost.
Messages are delivered to consumers that are bound to the endpoints that have received the guaranteed messages. Those messages are persisted on the event broker until they expire, or the consuming client acknowledges the messages, indicating they have been consumed.
Solace PubSub+'s Non-Persistent messaging delivery mode is primarily used to fulfill JMS specification requirements. It's also used in message promotion and demotion, which is explained in Message Promotion & Demotion. In general, only JMS client applications should use this mode directly when publishing.
In the previous discussions of Direct and Persistent (Guaranteed) messaging, both the producers and consumers made use of the same message delivery mode. However, it's possible for the producers and consumers to use different message delivery modes, thereby ending up with a hybrid of Direct and Persistent messaging, and this is achieved using message promotion and demotion.
Message promotion is the situation where the producer sends Direct messages, and the consumer receives these message from a Guaranteed messaging endpoint. In this case the consumer will receive Non-Persistent messages.
This is a typical scenario in applications where there is a real-time publisher sending events, and it's critical that this publisher never be back pressured. However, at the same time, there are some consumers that would like to receive the data in the most fault tolerant, Persistent way. In this scenario the consumers can receive the events using a queue endpoint with mapped topics. If the consumer application is ever offline, then messages will accumulate in the queue endpoint. The consumer application won't miss messages if it's offline or slow.
Message demotion is the situation where the producer sends Persistent messages, and there are consumers that want to receive these messages, but can tolerate lost messages. These consumers can add a topic subscription matching these messages, and receive them in real time as Direct messages. These consumers won't back pressure the publisher application, and if they go offline, those consumers will simply miss messages. Overall, the producer application is sending mission critical data, but some consumers of this data are not mission critical, and should never be allowed to affect the publishers.
From a consumer’s point-of-view, the only way to ensure fully guaranteed messaging is if the messages are received from an endpoint with a delivery mode of Persistent. That means the messages were sent persistently, and received on a Guaranteed messaging endpoint. All other combinations are examples of at-most-once messaging, and the Consumer will receive them either as Direct or Non-Persistent messages.
The following table outlines message promotion and demotion in
|Delivery Mode of Published Message||Received by Endpoint as…||Received by a Client with a Matching Topic Subscription as…|
Different protocols and APIs use different terminology to describe delivery modes. The following table provides a summary across the various protocols supported by the event broker.
|Message QoS||Solace APIs||JMS||MQTT||AMQP||Solace REST|
|At most once delivery||Direct (default)||Non-Persistent||QoS 0 (default)||
Direct for publishers only
(Direct subscribers not supported)
|At least once delivery||Persistent||Persistent||QoS 1||Persisted||Persistent (default)|
|Transacted||Session Based||Session + XA||N/A||N/A||N/A|