An endpoint’s purpose is to buffer messages for a consuming application. Some applications require all messages, whereas other applications require this guarantee only while they are connected. Solace supports both functionalities with durable and non-durable endpoints. In this post (and this video) I’ll explain how durability affects endpoints and their contents.
Introduction to Solace Endpoints
Solace endpoints are objects created on the event broker to persist messages. There are two types of endpoints: a queue endpoint (usually just called a queue) and a topic endpoint. For the differences between the two, check out my other blog.
Durable Endpoints
A durable endpoint is one that stays on the Solace broker until it is explicitly deleted. This endpoint can be created by an administrator, or dynamically created by an application. Durable endpoints are most often used when consuming applications require all messages including those received by the event broker when the application is disconnected.
As an example, imagine an order processing application. A consuming application must receive all order events to ensure each one is processed; any missed events could mean a loss in revenue. A durable endpoint would be used to ensure the consuming application receives all order events, even if they disconnect.
Non-durable Endpoints
A non-durable endpoint, also known as a temporary endpoint, has a shorter lifecycle and can only be created by an application. The endpoint has a lifespan of the client that created it, with an additional 60 seconds in case of unexpected disconnect. The 60 seconds provides the client with some time to reconnect to the endpoint before it and its contents are deleted from the Solace broker.
An example use case with non-durable endpoints could be an online search for flights. While connected to the system, a consumer would want to see all the available flights at that time. Should they disconnect, they would only want the latest search results and no stale results from a previous search. A non-durable endpoint could be used to buffer these search results while ensuring old results from previous searches are not present.
Permissions and Access
Message storage is a valuable resource on the event broker and administrators may want to control what applications have access to. Through the client-profile object, an administrator can separately control whether an application is able to dynamically create its own durable or non-durable endpoints, and how many it is able to create.
Endpoints also have their own permissions to control which applications can consume from them, modify them, and remove them. These permissions are set when the endpoint is initially created. If a client application creates an endpoint, it is automatically the owner of that endpoint and has full access to it.
It is also important to note that queues created by administrators cannot be removed by client applications, regardless of the permissions set on that endpoint.
Durable vs Non-Durable Endpoints
A durable endpoint can be created and deleted by administrators or applications; if created by an administrator, an application cannot delete the endpoint. Durable endpoints persist with a high availability (HA) failover and with a data replication (DR) failover. Non-durable endpoints can only be provisioned by applications and will remain on the broker if the client is connected, plus an additional 60 seconds for unexpected disconnects. Non-durable endpoints persist over HA failovers, however, due to the manual intervention required do not persist over DR failovers.
Durable endpoints can support multiple consumers, dependent on further configurations of that endpoint. Non-durable endpoints only support a single consumer, and the lifespan of that endpoint is dependent on that consumer.
The name for durable endpoints must be defined by the administrator or application that provisions it, while non-durable endpoints also provide automatically generated names.
Which durability should you use?
Your endpoint durability will relate exactly to the quality of service required by the consuming application. If your application requires all messages even when a disconnect occurs, a durable endpoint should be used. If your application can tolerate loss, or only requires messages while it is connected, a non-durable endpoint can be used.
Conclusion
I hope this post has helped you understand the concept of endpoint durability, and how durability affects the two types of endpoints that Solace supports, along with their contents. In case you missed the link above, I’ve embedded below a video version of the same content. If you found this post useful, you can visit the endpoints section of our docs and our PubSub+ for Developers page for more information. You can also check out some sample code on Github.
If you have any questions about queues and topic endpoints, try posting them to the Solace Developer Community.
The post Understanding Solace Endpoints: Durable vs. Non-Durable appeared first on Solace.
Top comments (0)