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.
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’.
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:
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.
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.
Join the Solace Developer Community to discuss and share PubSub+ API hints, new features, useful integrations, demos, and sample code!