Message Delivery Modes
- At-most-once delivery
-
Non-persistent message delivery mode is used to fulfill JMS specification requirements. For Solace Messaging APIs, non-persistent messages perform the same function as persistent messages.
- At-least-once delivery
-
- Transacted delivery
-
Direct
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 for consuming clients (in other words, they're not persisted) nor acknowledged when received.
Learn More:
Persistent (Guaranteed)
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.
Learn More:
Publishing Guaranteed Messages
Clients can publish to either a queue or a 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.
Receiving Guaranteed Messages
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.
Non-Persistent
Non-persistent messaging delivery mode is used to fulfill JMS specification requirements. It's also used in message promotion and demotion, which is explained in Message Promotion and Demotion. Only JMS client applications should use this mode directly when publishing.
Message Promotion and Demotion
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 and demotion can introduce several potential drawbacks to your deployment. Carefully consider the following limitations before deciding to implement this feature:
-
Message promotion is not guaranteed to be lossless. A Direct message publisher can send messages faster than the Guaranteed messaging path can process messages and it doesn’t have the same backpressure mechanisms as a Guaranteed publisher. In this case, the event broker aggressively discards messages on the promotion path to protect the Guaranteed messaging path.
-
Message promotion can lead to resource issues. Because a Direct message publisher can send messages faster than a Guaranteed messaging client can consume them, the disk space allocated for queues on the event broker can be quickly consumed.
-
A high rate of message promotion can impact latency for Guaranteed messaging.
-
Message demotion can result in duplicate messages. If the publishing application doesn’t receive acknowledgement from the event broker, messages are retransmitted. The event broker has built in mechanisms to prevent this retransmission for Guaranteed messaging subscribers, however Direct messaging subscribers receive additional copies.
For additional guidance, contact Solace.
Message promotion
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
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.
Summary
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… |
|---|---|---|
| Direct | Non-persistent | Direct |
| Non-Persistent | Non-persistent | Direct |
| Persistent | Persistent | Direct |
Learn More:
Message Delivery Modes Terminology
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) |
Direct |
| At-least-once delivery | Persistent | Persistent | QoS 1 | Persisted | Persistent (default) |
| Transacted | Session based | Session + XA | N/A | N/A | N/A |