The Fuse Message Broker message store has undergone a process of evolution. Currently, the KahaDB message store is the default (and recommended) message store, while the AMQ message store and the (original) kaha message store represent earlier generations of message store technology.
The KahaDB architecture—as shown in Figure 2.3—is designed to facilitate high-speed message storage and retrieval. The bulk of the data is stored in rolling journal files (data logs), where all broker events are continuously appended. In particular, pending messages are also stored in the data logs.
In order to facilitate rapid retrieval of messages from the data logs, a B-tree index is created, which contains pointers to the locations of all the messages embedded in the data log files. The complete B-tree index is stored on disk and part or all of the B-tree index is held in a cache in memory. Evidently, the B-tree index can work more efficiently, if the complete index fits into the cache.
The following example shows how to configure a broker to use the KahaDB message
store, by adding a persistenceAdapter element containing a
kahaDB child element:
<broker brokerName="broker" persistent="true" useShutdownHook="false"> ... <persistenceAdapter> <kahaDB directory="activemq-data" journalMaxFileLength="32mb"/> </persistenceAdapter> </broker>
The directory property specifies the directory where the KahaDB files
are stored and the journalMaxFileLength specifies the maximum size of a
data log file.
You can optimize the performance of the KahaDB message store by modifying the
following properties (set as attributes on the kahaDB element):
indexCacheSize—(default10000) specifies the size of the cache in units of pages (where one page is 4 KB by default). Generally, the cache should be as large as possible, to avoid swapping pages in and out of memory. Check the size of your metadata store file,db.data, to get some idea of how big the cache needs to be.indexWriteBatchSize—(default1000) defines the threshold for the number of dirty indexes that are allowed to accumulate, before KahaDB writes the cache to the store. If you want to maximize the speed of the broker, you could set this property to a large value, so that the store is updated only during checkpoints. But this carries the risk of losing a large amount of metadata, in the event of a system failure (causing the broker to restart very slowly).journalMaxFileLength—(default32mb) when the throughput of a broker is very large, you can fill up a journal file quite quickly. Because there is a cost associated with closing a full journal file and opening a new journal file, you can get a slight performance improvement by increasing the journal file size, so that this cost is incurred less frequently.enableJournalDiskSyncs—(defaulttrue) normally, the broker performs a disk sync (ensuring that a message has been physically written to disk) before sending the acknowledgment back to a producer. You can obtain a substantial improvement in broker performance by disabling disk syncs (setting this property tofalse), but this reduces the reliability of the broker somewhat.![[Warning]](imagesdb/warning.gif)
Warning If you need to satisfy the JMS durability requirement and be certain that you do not lose any messages, do not disable journal disk syncs.
For more details about these KahaDB configuration properties, see Optimizing the Metadata Cache in Using Persistent Messages and Configuring the KahaDB Message Store in Using Persistent Messages.
 |  |  |
 |
