6.3. HornetQ's Journal

Aside from enabling native asynchronous I/O (if installed on RHEL), the next configuration parameter to optimize is the journal's location, relative to the file system configuration. The default configuration places the journal in ${jboss.server.data.dir}/${hornetq.data.dir}:hornetq/journal, which expands to: JBOSS_EAP_DIST/jboss-as/server/PROFILE/data/hornetq/journal. Note that the minimal configuration does not contain the JMS provider.
Depending on the underlying storage configuration, this may not be the optimal location. A common configuration is to locate rarely-accessed file (e.g. executables/binaries) on relatively slow, cheaper storage and often-accessed files (e.g. log files, journaling files) on high-performance, more expensive storage. If you have very high messaging loads, the journal should be placed on a high-performance file system, with a high-performance disk configuration. In general, HornetQ's performance is bound by the speed of the file system and network so the configuration of these are most likely be governing factors of performance. To change the location of the journal, the HornetQ configuration file needs to be modified. The configuration file is called hornetq-configuration.xml, in the directory JBOSS_EAP_DIST/jboss-as/server/PROFILE/deploy/hornetq/.
Below is an extract from the configuration file:
<configuration xmlns="urn:hornetq"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:hornetq /schema/hornetq-configuration.xsd">
<!--  Do not change this name.
   This is used by the dependency framework on the deployers,
   to make sure this deployment is done before any other deployment -->
<name>HornetQ.main.config</name>
<clustered>true</clustered>
<log-delegate-factory-class-name>org.hornetq.integration.logging.Log4jLogDelegateFactory</log-delegate-factory-class-name>
<bindings-directory>${jboss.server.data.dir}/${hornetq.data.dir:hornetq}/bindings</bindings-directory>
<journal-directory>${jboss.server.data.dir}/${hornetq.data.dir:hornetq}/journal</journal-directory>
<journal-min-files>10</journal-min-files>
<large-messages-directory>${jboss.server.data.dir}/${hornetq.data.dir:hornetq}/largemessages</large-messages-directory>
<paging-directory>${jboss.server.data.dir}/${hornetq.data.dir:hornetq}/paging</paging-directory>
</configuration>
From the above extract, the following directories are of interest:
  • journal-directory
  • large-messages-directory
  • paging-directory
The location specified for journal-directory is the most critical with respect to performance but the others can also have a significant impact.
The journal-directory is where persistent messages are stored.
The large-message directory is used to store messages that are larger than can fit into memory. If the application processes large messages, this is also a performance critical directory.
The paging-directory is similar to the large message directory, except that is an accumulation of many messages, that no longer fit into memory or are swapped/paged to disk, which is analogous to operating system paging to swap. Just like the journal and large message directory, this is also a performance critical directory, if swapping/paging occurs.
There are two ways to change the locations to be used by these directories. First, you can change the ${jboss.server.data.dir} variable, by passing -Djboss.server.data.dir=<path> where path is the new directory location (higher performance file system and disk configuration). This will have the effect of moving everything that uses that directory to the new location, not just the HornetQ directories. This approach has an added bonus because there is another performance critical directory under that path, which contains the transaction journal. Transactions are logged for crash recovery purposes within this same path and this can also benefit from being located on higher-performing storage. The other option is to change the configuration directly, remove the ${jboss.server.data.dir} and replace it with the new location. In either case, moving this to faster storage will improve performance. Using the command-line option method is easiest because it uses the variable, so there's no need to change the configuration file.