KahaDB is a file based persistence database that is local to the message broker that is using it. It has been optimised for fast persistence and is the the default storage mechanism from ActiveMQ 5.4 onwards. KahaDB uses less file descriptors and provides faster recovery than its predecessor, the AMQ Message Store.

Configuration

You can configure ActiveMQ to use KahaDB for its persistence adapter - like below:

KahaDB Properties

the path to the directory to use to store the message store data and log files

IndexDirectory

If set, configures where the KahaDB index files will be stored. If not set, the index files are stored in the directory specified by the 'directory' attribute.

Available as of ActiveMQ 5.10

indexWriteBatchSize

1000

number of indexes written in a batch

indexCacheSize

10000

number of index pages cached in memory

enableIndexWriteAsync

false

if set, will asynchronously write indexes

journalMaxFileLength

32mb

a hint to set the maximum size of the message data logs

enableJournalDiskSyncs

true

ensure every journal write is followed by a disk sync (JMS durability requirement)

cleanupInterval

30000

time (ms) before checking for a discarding/moving message data logs that are no longer used

checkpointInterval

5000

time (ms) before checkpointing the journal

ignoreMissingJournalfiles

false

If enabled, will ignore a missing message log file

checkForCorruptJournalFiles

false

If enabled, will check for corrupted Journal files on startup and try and recover them

checksumJournalFiles

false true v5.9

create a checksum for a journal file - to enable checking for corrupted journals

archiveDataLogs

false

If enabled, will move a message data log to the archive directory instead of deleting it.

directoryArchive

null

Define the directory to move data logs to when they all the messages they contain have been consumed.

maxAsyncJobs

10000

the maximum number of asynchronous messages that will be queued awaiting storage (should be the same as the number of concurrent MessageProducers)

concurrentStoreAndDispatchTopics

false

enable the dispatching of Topic messages to interested clients to happen concurrently with message storage (Warning: Enabling this property is not recommended)

concurrentStoreAndDispatchQueues

true

enable the dispatching of Queue messages to interested clients to happen concurrently with message storage

archiveCorruptedIndex

false

If enabled, corrupted indexes found at startup will be archived (not deleted)

preallocationStrategy

sparse_file

(as of 5.12.0) This setting configures how the broker will try to preallocate the journal files when a new journal file is needed. The default allocation strategy sets the file length, but does not populate it with any data. The 'os_kernel_copy' strategy delegates the preallocation to the Operating System. The 'zeros' strategy configures ActiveMQ to do the preallocation by writing 0x00 to all of the positions in the journal file.

You can configure a threshold used to log these messages by using a system property and adjust it to your disk speed so that you can easily pick up runtime anomalies.

-Dorg.apache.activemq.store.kahadb.LOG_SLOW_ACCESS_TIME=1500

Multi(m) kahaDB persistence adapter

From 5.6, it is possible to distribute destinations stores across multiple kahdb persistence adapters. When would you do this? If you have one fast producer/consumer destination and another periodic producer destination that has irregular batch consumption, you disk usage can grow out of hand because unconsumed messages get dotted across journal files. Having a separate journal for each ensures minimal journal usage. Also, some destination may be critical and require disk synchronisation while others may not. In these cases you can use the mKahaDB persistence adapter and filter destinations using wildcards, just like with destination policy entries.

Transactions

Transactions can span multiple journals if the destinations are distributed. This means that two phase completion is necessary, which does impose a performance (additional disk sync) penalty to record the commit outcome. This penalty is only imposed if more than one journal is involved in a transaction.

Configuration

Each instance of kahaDB can be configured independently. If no destination is supplied to a filteredKahaDB, the implicit default value will match any destination, queue or topic. This is a handy catch all. If no matching persistence adapter can be found, destination creation will fail with an exception. The filteredKahaDB shares its wildcard matching rules with Per Destination Policies.