Appendix E. Messaging Journal Configuration Elements

download PDF

The table below lists all of the configuration elements related to the AMQ Broker messaging journal.

Table E.1. Address Setting Elements


The directory where the message journal is located. The default value is BROKER_INSTANCE_DIR/data/journal.

For the best performance, the journal should be located on its own physical volume in order to minimize disk head movement. If the journal is on a volume that is shared with other processes that may be writing other files (for example, bindings journal, database, or transaction coordinator) then the disk head may well be moving rapidly between these files as it writes them, thus drastically reducing performance.

When using a SAN, each journal instance should be given its own LUN (logical unit).


If set to true, the journal directory will be automatically created at the location specified in journal-directory if it does not already exist. The default value is true.


Valid values are NIO or ASYNCIO.

If set to NIO, the broker uses Java NIO interface to itsjournal. Set to ASYNCIO, and the broker will use the Linux asynchronous IO journal. If you choose ASYNCIO but are not running Linux or you do not have libaio installed then the broker will detect this and automatically fall back to using NIO.


If set to true, the broker flushes all transaction data to disk on transaction boundaries (that is, commit, prepare, and rollback). The default value is true.


If set to true, the broker flushes non-transactional message data (sends and acknowledgements) to disk each time. The default value is true.


The size of each journal file in bytes. The default value is 10485760 bytes (10MiB).


The minimum number of files the broker pre-creates when starting. Files are pre-created only if there is no existing message data.

Depending on how much data you expect your queues to contain at steady state, you should tune this number of files to match the total amount of data expected.


The system will create as many files as needed; however, when reclaiming files it will shrink back to journal-pool-files.

The default value is -1, meaning it will never delete files on the journal once created. The system cannot grow infinitely, however, as you are still required to use paging for destinations that can grow indefinitely.


Controls the maximum number of write requests that can be in the IO queue at any one time. If the queue becomes full then writes will block until space is freed up.

When using NIO, this value should always be 1. When using AIO, the default value is 500. The total max AIO can’t be higher than the value set at the OS level (/proc/sys/fs/aio-max-nr), which is usually at 65536.


Controls the timeout for when the buffer will be flushed. AIO can typically withstand with a higher flush rate than NIO, so the system maintains different default values for both NIO and AIO.

The default value for NIO is 3333333 nanoseconds, or 300 times per second, and the default value for AIO is 50000 nanoseconds, or 2000 times per second.


By increasing the timeout value, you might be able to increase system throughput at the expense of latency, since the default values are chosen to give a reasonable balance between throughput and latency.


The size of the timed buffer on AIO. The default value is 490KiB.


The minimal number of files necessary before the broker compacts the journal. The compacting algorithm will not start until you have at least journal-compact-min-files. The default value is 10.


Setting the value to 0 will disable compacting and could be dangerous because the journal could grow indefinitely.


The threshold to start compacting. Journal data will be compacted if less than journal-compact-percentage is determined to be live data. Note also that compacting will not start until you have at least journal-compact-min-files data files on the journal. The default value is 30.

Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.