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 :

 <broker brokerName="broker" ... >
    <persistenceAdapter>
      <kahaDB directory="activemq-data" journalMaxFileLength="32mb"/>
    </persistenceAdapter>
    ...
  </broker>

KahaDB Properties

Slow file system access diagnostic logging

You can configure a non zero threshold in mili seconds for database updates.
If database operation is slower than that threshold (for example if you set it to 500), you may see messages like

Slow KahaDB access: cleanup took 1277 | org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal Checkpoint Worker

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.

<broker brokerName="broker" ... >
 <persistenceAdapter>
  <mKahaDB directory="${activemq.base}/data/kahadb">
    <filteredPersistenceAdapters>
      <!-- match all queues -->
      <filteredKahaDB queue=">">
        <persistenceAdapter>
          <kahaDB journalMaxFileLength="32mb"/>
        </persistenceAdapter>
      </filteredKahaDB>
      
      <!-- match all destinations -->
      <filteredKahaDB>
        <persistenceAdapter>
          <kahaDB enableJournalDiskSyncs="false"/>
        </persistenceAdapter>
      </filteredKahaDB>
    </filteredPersistenceAdapters>
  </mKahaDB>
 </persistenceAdapter>
...
</broker>

Automatic per destination persistence adapter

When the perDestination boolean attribute is set to true on the catch all (no explicit destination set), filteredKahaDB. Each matching destination will get its own kahaDB instance.

<broker brokerName="broker" ... >
 <persistenceAdapter>
  <mKahaDB directory="${activemq.base}/data/kahadb">
    <filteredPersistenceAdapters>
      <!-- kahaDB per destinations -->
      <filteredKahaDB perDestination="true" >
        <persistenceAdapter>
          <kahaDB journalMaxFileLength="32mb" />
        </persistenceAdapter>
      </filteredKahaDB>
    </filteredPersistenceAdapters>
  </mKahaDB>
 </persistenceAdapter>
...
</broker>