Topic Subscription on Queues
In this blog post, I will be discussing a Solace feature called “Topic Subscription on
Solace supports two main delivery modes, also known as qualities of service: direct messaging that delivers a message one time at most, and persistent messaging that guarantees delivery at least once.
This short blog series will provide an overview of the delivery modes.
Direct Messaging
Direct messaging is over Transmission Control Protocol (TCP) and is therefore a reliable method of moving data. You can think of it as a ‘fire and forget’ model, where the publishing application sends the data to the Solace event broker and does not expect confirmation that the message was received.
Direct messaging is used when data is not always required on the consuming end – as an example, consider GPS location updates. A consuming application would still have enough information about a vehicles location even if it misses a few updates, so receiving every single message is nice, but not critical, in this scenario.
Persistent Messaging
Persistent messaging is also over TCP but has an additional set of acknowledgements beyond those used by TCP itself. When a message is sent as persistent, the broker acknowledges receipt of that message when the message is saved in an endpoint on the broker.
To ensure message delivery, a message is also acknowledged by a consuming application once it has been received from the Solace event broker and has been processed. There are two acknowledgments that occur on the consuming side; one to confirm the application has received the message (Transport/API ACK), and one to confirm the application is done with the message (Application/Client ACK). The first acknowledgement allows the Solace event broker to send more messages to the consuming application – this increases efficiency as the consuming application will have buffered a set of messages ready to be processed. The second acknowledgement is sent when the consuming application is done processing the message and no longer requires that data – this acknowledgment removes the message from the endpoint on the Solace event broker.
Persistent messaging with Solace occurs between the publishing application and the broker, and between the broker and the consuming application. If the consuming application is not connected or cannot keep up with the publishing application, the messages are stored in endpoints on the Solace event broker.
Persistent messaging is used when data must be received by the consuming application, even if they are offline, and data can’t be lost. An example is an online store where any loss in messages could mean a missed revenue opportunity, lost customer, or a too-late decision to replenish inventory of a hot-selling product.
Exactly Once Delivery
In most situations, Solace’s persistent messaging quality of service provides exactly once delivery of messages where data is received, processed, and acknowledged. However, a message can be sent to a consumer multiple times when acknowledgements are not received as expected by the broker.
If a message is sent to a consuming application and the API ACK is received, the broker knows the consuming application has the message but has not yet completed processing of that message. If the consuming application were to disconnect from and reconnect to the broker, Solace would resend the message to the consuming application to ensure it will be processed. In this situation, the consuming application would need to verify if it has already processed the data and send the Application ACK to the broker to remove the message from the endpoint.
This safety mechanism ensures the data is received by the consuming application and there is no message loss. Consuming applications should have duplicate message handling for this exact situation. Solace also supports transactions, should your message flow require ACID properties.
How Do I Set Delivery Mode?
On the publishing side, the delivery mode is dependent on the message property ‘Delivery Mode’. This property can be set to ‘DIRECT’ or to ‘PERSISTENT’. Below is an example of how this is set in the Solace Java API, JCSMP:
Message.setDeliveryMode(‘PERSISTENT’);
Note: queues can have topic subscriptions applied to them to get a publish-subscribe persistent messaging exchange pattern. You can read more in this blog.
The consuming side delivery mode is dependent on how the consuming application subscribes to the data. If the application applies a topic subscription to its connection, it receives data via direct messaging. If the application binds to an endpoint, it will receive the data in a persistent manner.
To summarize the Solace delivery modes, direct messaging is an example of at most once delivery, where data is sent in a reliable manner, but is not guaranteed. Guaranteed or persistent messaging is an example of at least once delivery, where data will be guaranteed to reach its destination.
In the next blog post in this series, I will explain how messages can be promoted and demoted. I hope this post has helped you understand the concept of message delivery modes. If you found this post useful, visit this section of our docs, and our PubSub+ for Developers page for more information. If you have any questions about message delivery modes, try posting them to the Solace Developer Community.
Subscribe to Our Blog
Get the latest trends, solutions, and insights into the event-driven future every week.
Related Posts
Understanding Solace Endpoints: Durable vs. Non-Durable
An endpoint’s purpose is to buffer messages for a consuming application. Some applications require all
Implementing Transactional Messaging with Solace
In this blog, I’ll introduce you to Session Transactions, commonly called Local Transactions. Transacted Sessions
Understanding Solace Endpoints: Message Queue Access Types for Consumers
(Updated in April 2023 to reflect the introduction of partitioned queues) The concept of message
Understanding Solace Endpoints: Queues vs. Topic Endpoints
One of the most frequent questions customers ask me is “What is the difference between
Inside a Solace Message, Part 1: An Introduction
It’s a fairly obvious statement that a message contains a header and a payload, the
Inside a Solace Message, Part 2: Using Header Properties
The first post in this series introduced the basic elements and properties of a Solace
Inside a Solace Message, Part 3: Payload Data
In the first post of this series I introduced the structure of Solace messages, and in part
PubSub+ Message Handling Features: Dead Message Queues
In the first blog in this series, I explained the concept of message expiry, or
PubSub+ Message Handling Features: Reject-Message-to-Sender-on-Discard
Thus far in the message handling features blog series we have looked at message expiry