Chapter 13. Persistence

This chapter covers persistence and its configuration in HornetQ.
HornetQ handles its own persistence. It ships with a high-performance journal, which is optimized for messaging-specific use cases.
The HornetQ journal is append only with a configurable file size, which improves performance by enabling single write operations. It consists of a set of files on disk, which are initially pre-created to a fixed size and filled with padding. As server operations (add message, delete message, update message, etc.) are performed, records of the operations are appended to the journal until the journal file is full, at which point the next journal file is used.
A sophisticated garbage collection algorithm determines whether journal files can be reclaimed and re-used when all of their data has been deleted. A compaction algorithm removes dead space from journal files and compresses the data.
The journal also fully supports both local and XA transactions.
The majority of the journal is written in Java, but interaction with the file system has been abstracted to allow different pluggable implementations. The two implementations shipped with HornetQ are:
Java Non-blocking IO (NIO)
Uses standard Java NIO to interface with the file system. This provides extremely good performance and runs on any platform with a Java 6 or later runtime.
Linux Asynchronous IO (AIO)
Uses a native code wrapper to talk to the Linux asynchronous IO library (AIO). With AIO, HornetQ receives a message when data has been persisted. This removes the need for explicit syncs. AIO will typically provide better performance than Java NIO, but requires Linux kernel 2.6 or later and libaio.
AIO also requires ext2, ext3, ext4, jfs or xfs type file systems. On NFS, AIO falls back to slower, synchronous behavior.

Note

On Red Hat Enterprise Linux, install libaio with the following command:
yum install libaio
The standard HornetQ core server uses the following journal instances:
bindings journal
Stores bindings-related data, including the set of queues deployed on the server and their attributes. It also stores data such as ID sequence counters. The bindings journal is always a NIO journal, as it typically has low throughput in comparison to the message journal.
The files on this journal are prefixed as hornetq-bindings. Each file has a bindings extension. File size is 1048576 bytes, and it is located in the bindings folder.
JMS journal
Stores all JMS-related data, for example, any JMS queues, topics or connection factories and any JNDI bindings for these resources. Any JMS resources created with the management API are persisted to this journal. Any resources configured with configuration files are not. This journal is created only if JMS is in use.
message journal
Stores all message-related data, including messages themselves and duplicate-id caches. By default, HornetQ uses AIO for this journal. If AIO is not available, it will automatically fall back to NIO.
Large messages are persisted outside the message journal. For more information see Chapter 21, Large Messages.
In low memory situations, configure HornetQ to page messages to disk. See Chapter 22, Paging for more information.
If persistence is not required, HornetQ can be configured not to persist any data, as discussed in Section 13.4, “Configuring HornetQ for Zero Persistence”.

13.1. Configuring the bindings journal

The bindings journal is configured using the following attributes in <JBOSS_HOME>/jboss-as/server/<PROFILE>/deploy/hornetq/hornetq-configuration.xml.
bindings-directory
The location of the bindings journal. The default value is data/bindings.
create-bindings-dir
If true, and the bindings directory does not exist, the bindings directory is created automatically at the location specified in bindings-directory. The default value is true.