This topic has not yet been written. The content below is from the topic description.
Chapter 15. Persistence In this chapter we will describe how persistence works with HornetQ and how to configure it. HornetQ ships with a high performance journal. Since HornetQ handles its own persistence, rather than relying on a database or other 3rd party persistence engine it is very highly optimised for the specific messaging use cases. A HornetQ journal is an append only journal. It consists of a set of files on disk. Each file is pre-created to a fixed size and initially filled with padding. As operations are performed on the server, e.g. add message, update message, delete message, records are appended to the journal. When one journal file is full we move to the next one. Because records are only appended, i.e. added to the end of the journal we minimise disk head movement, i.e. we minimise random access operations which is typically the slowest operation on a disk. Making the file size configurable means that an optimal size can be chosen, i.e. making each file fit on a disk cylinder. Modern disk topologies are complex and we are not in control over which cylinder(s) the file is mapped onto so this is not an exact science. But by minimising the number of disk cylinders the file is using, we can minimise the amount of disk head movement, since an entire disk cylinder is accessible simply by the disk rotating - the head does not have to move. As delete records are added to the journal, HornetQ has a sophisticated file garbage collection algorithm which can determine if a particular journal file is needed any more - i.e. has all it's data been deleted in the same or other files. If so, the file can be reclaimed and re-used. HornetQ also has a compaction algorithm which removes dead space from the journal and compresses up the data so it takes up less files on disk. The journal also fully supports transactional operation if required, supporting both local and XA transactions. The majority of the journal is written in Java, however we abstract out the interaction with the actual file system to allow different pluggable implementations. HornetQ ships with two implementations: Java NIO. The first implementation uses standard Java NIO to interface with the file system. This provides extremely good performance and runs on any platform where there's a Java 6+ runtime. Linux Asynchronous IO The second implementation uses a thin native code wrapper to talk to the Linux asynchronous IO library (AIO). With AIO, HornetQ will be called back when the data has made it to disk, allowing us to avoid explicit syncs altogether and simply send back confirmation of completion when AIO informs us that the data has been persisted. Using AIO will typically provide even better performance than using Java NIO. The AIO journal is only available when running Linux kernel 2.6 or later and after having installed libaio (if it's not already installed). For instructions on how to install libaio please see Section 15.5, “Installing AIO�. Also, please note that AIO will only work with the following file systems: ext2, ext3, ext4, jfs, xfs. With other file systems, e.g. NFS it may appear to work, but it will fall back to a slower sychronous behaviour. Don't put the journal on a NFS share! For more information on libaio please see Chapter 40, Libaio Native Libraries. libaio is part of the kernel project. The standard HornetQ core server uses two instances of the journal: Bindings journal. This journal is used to store bindings related data. That includes the set of queues that are 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 is typically low throughput compared to the message journal. The files on this journal are prefixed as hornetq-bindings. Each file has a bindings extension. File size is 1048576, and it is located at the bindings folder. JMS journal. This journal instance stores all JMS related data, This is basically any JMS Queues, Topics and Connection Factories and any JNDI bindings for these resources. Any JMS Resources created via the management API will be persisted to this journal. Any resources configured via configuration files will not. The JMS Journal will only be created if JMS is being used. The files on this journal are prefixed as hornetq-jms. Each file has a jms extension. File size is 1048576, and it is located at the bindings folder. Message journal. This journal instance stores all message related data, including the message themselves and also duplicate-id caches. By default HornetQ will try and use an AIO journal. If AIO is not available, e.g. the platform is not Linux with the correct kernel version or AIO has not been installed then it will automatically fall back to using Java NIO which is available on any Java platform. The files on this journal are prefixed as hornetq-data. Each file has a hq extension. File size is by the default 10485760 (configurable), and it is located at the journal folder. For large messages, HornetQ persists them outside the message journal. This is discussed in Chapter 23, Large Messages. HornetQ can also be configured to page messages to disk in low memory situations. This is discussed in Chapter 24, Paging. If no persistence is required at all, HornetQ can also be configured not to persist any data at all to storage as discussed in Section 15.6, “Configuring HornetQ for Zero Persistence�.