Message handling features can help administrators and developers control how messages behave on the event broker and how they are received by consumers. This is the first in a series of blog posts in which I’ll introduce the various message handling features supported by Solace PubSub+ Event Brokers, starting with message expiry. Before reading this you should be familiar with both Solace endpoints and Solace persistent messaging.
What is Message Expiry?
Message expiry is a timer that dictates the lifespan of the message. The message will persist on an endpoint until that timer expires. Without this timer, a message will persist on a Solace endpoint indefinitely, or until it is consumed by an application or deleted by an administrator.
Message expiry is also commonly referred to as ‘message time-to-live’ or ‘message-TTL’.
How do I use message expiry with Solace PubSub+ Event Broker?
When considering message expiry, you need to consider a couple of required configurations. First, your endpoint must ‘Respect-TTL’ – this setting informs the endpoint to actively check messages for a TTL value. Next, you must set the TTL for the message.
There are two options to set the TTL:
- Set ‘Maximum TTL’ on the endpoint. This will apply to all messages that are stored in the endpoint and is measured in seconds.
- The publisher optionally sets the ‘Message-TTL’ on the message before sending it. This method allows the publisher to decide how long each message should live and if each message requires a TTL. This value is measured in milliseconds.
It is possible to set both the Message-TTL and the queue Max-TTL. The lower of the two is used for expiry.
Is it possible to set the TTL value in seconds when creating a new queue via JMS?Find out the answer from experts at Solace.
Once a message has expired, the default behavior is that the message is deleted from the endpoint. It is also possible to have the message move to a Dead-Message-Queue, for special error or behaviour handling. When a message is expired from the endpoint, the discard statistics will reflect this.
What are some use cases for message expiry?
Message expiry, especially when set on the queue itself, is particularly useful in development environments where messages are sent to queues and are not consumed. To prevent the queue from filling up, you can use TTL to remove messages from a development queue as needed.
A use case example of message expiry could be an order management system that must process orders in a timely manner. For orders that are not processed in the desired amount of time, they could be expired to a Dead-Message-Queue for special, expedited processing or for error handling.
Another example could be an application that receives flight statuses. If a flight status is not consumed within a couple of hours, possibly due to the consuming application being unavailable, the flight status may no longer be relevant and is no longer required. The message could then be expired and removed from the endpoint.
If you found this post useful, visit the message properties section of our docs, and our PubSub+ for Developers page for more information. If you have any questions about queues and topic endpoints, post them to the Solace Developer Community.
Subscribe to Our Blog
Get the latest trends, solutions, and insights into the event-driven future every week.
By submitting this form, you agree to Solace’s privacy policy: solace.com/privacy-policy/