Skip to main content


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.

  <timeStampingBrokerPlugin ttlCeiling="86400000" zeroExpirationOverride="86400000"/>

The full documentation is here:

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.

Jonathan Gallimore

Jonathan Gallimore

Jonathan Gallimore is a passionate Apache TomEE committer, developer and trainer at Tomitribe. He started contributing to Apache TomEE in 2007, working on EJB 3.1 compliance, OpenEJB Eclipse Plug-in, early Tomcat 7 integration (that became the basis for TomEE) and the first version of the TomEE Arquillian adapter. Jon has worked as a developer and architect on Java EE projects across the media, banking, and sports industries.

Leave a Reply