Clean-up of unreferenced KahaDB journal log files data-<id>.log will occur every 30 seconds by default. If a data file is in-use it will not be cleaned up.
A data file may be in-use because:
The trace level logging of the org.apache.activemq.store.kahadb.MessageDatabase class provides insight into the cleanup process and will allow you to determine why a given data file is considered in-use and as a result, not a candidate for cleanup.
To debug, add the following (or similar) to your log4j.properties file (if needed):
Either restart AMQ and let the cleanup process run (give it a minute or two for example) or alternatively apply this logging configuration to a running broker via JMX. The "Broker" MBean exposes an operation called "reloadLog4jProperties" in JMX that can be used to tell the broker to reload its log4j.properties. Often its enough to apply this logging configuration for 2-5 minutes and then analyze the broker's log file.
Examine the log file and look for cleanup of the data files. The process starts with the complete set of known data files and queries the index on a per destination basis to prune this list. Anything that remains is a candidate for cleanup.
At some point you'll hit a destination and the number of data file ids will suddenly drop because that destination references them. It could be a DLQ or an offline durable subscriber.
Here is a quick sample
We get one candidate, data-87.log from the existing set of journal data files
Similar for non-persistent messages that are not stored in your configured KahaDB persistence adapter but get swapped to temp storage once they exceed the broker's configured memoryUsage limit. A similar logging configuration can show details of the cleanup of temp storage.
Note the last line of above logging configuration disables the verbose logging of the kahadb cleanup task. If that line gets removed, the cleanup details of both kahadb and temp storage will be logged to the same file but you need to be careful not to mix the logging output.