Introduction
This article is a quick tip for ActiveMQ users, and introduces the Time Stamp Plugin.
Common support queries we get with ActiveMQ are the broker running out of space, or Producer Flow Control kicking in. Often, the cause is simple: messages have been sent to the broker, and haven’t been consumed.
This will be exacerbated if you have multiple destinations, and particularly if you use KahaDB for persistence (which is the default). See my post here to get a 10000 ft view on how KahaDB works under the covers, and how it can use a large amount of disk space, even if a small number of messages are not consumed.
Controlling message expiry
When a message is delivered to a persistent destination, it will stay there until it is either consumed, or expires.
Message expiry can be controlled by the system producing the message and sending it to the broker, either by using setTimeToLive() on the MessageProducer, or passing a Time To Live (TTL) value to the MessageProducer.send() method. In both cases, the TTL is specified in milliseconds.
The default time to live, per the JMS specification, is 0 (unlimited).
Time Stamp Plugin
In an ideal world, producers will use an appropriate TTL when dispatching messages to the broker, and consumers will quickly and efficiently process messages. As someone responsible for an ActiveMQ broker, you may not be in control of either of these things. Enter the Time Stamp Plugin. Very simply, this plugin will set a default TTL for messages that do not have one set (the zeroExpirationOverride setting), and will also enforce a maximum TTL time (the ttlCeiling setting).
The following config will force any message without a TTL to expire 24 hours after it is sent, and any message with a TTL longer than 24 hours will have its TTL reduced to 24 hours.
<plugins>
<timeStampingBrokerPlugin ttlCeiling="86400000" zeroExpirationOverride="86400000"/>
</plugins>The full documentation is here: https://activemq.apache.org/timestampplugin
The Dead Letter Queue
That’s not quite the end of the story, as expired messages will be moved to the Dead Letter Queue (DLQ). Its important to monitor the DLQ and handle any messages in it as appropriate.
