activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [1/2] activemq-artemis git commit: ARTEMIS-1037 Doc for the MAPPED journalType
Date Thu, 16 Mar 2017 14:24:35 GMT
Repository: activemq-artemis
Updated Branches:
  refs/heads/master dca124f9a -> 4936291ae

ARTEMIS-1037 Doc for the MAPPED journalType


Branch: refs/heads/master
Commit: 14d07ba7d14b0b50ad056d85e97ece173a966f75
Parents: dca124f
Author: Francesco Nigro <>
Authored: Tue Mar 14 13:09:21 2017 +0100
Committer: Clebert Suconic <>
Committed: Thu Mar 16 10:24:26 2017 -0400

 docs/user-manual/en/ |  4 +--
 docs/user-manual/en/         |  5 ++++
 docs/user-manual/en/         | 35 ++++++++++++++++++++++++-
 3 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/docs/user-manual/en/ b/docs/user-manual/en/
index 955c87b..d66b8b0 100644
--- a/docs/user-manual/en/
+++ b/docs/user-manual/en/
@@ -74,13 +74,13 @@ Name | Description
 [journal-compact-percentage](                                        |  The
percentage of live data on which we consider compacting the journal. Default=30
 [journal-directory](                                                 |  the
directory to store the journal files in. Default=data/journal
 [journal-file-size](                                                 |  the
size (in bytes) of each journal file. Default=10485760 (10 MB)
-[journal-max-io](           | 
the maximum number of write requests that can be in the AIO queue at any one time. Default
is 500 for AIO and 1 for NIO.
+[journal-max-io](           | 
the maximum number of write requests that can be in the AIO queue at any one time. Default
is 500 for AIO and 1 for NIO, ignored for MAPPED.
 [journal-min-files](     | 
how many journal files to pre-create. Default=2
 [journal-pool-files](     |
 The upper theshold of the journal file pool,-1 (default) means no Limit. The system will
create as many files as needed however when reclaiming files it will shrink back to the `journal-pool-files`
 [journal-sync-non-transactional](                                      | 
if true wait for non transaction data to be synced to the journal before returning response
to client. Default=true
 [journal-sync-transactional](                                          | 
if true wait for transaction data to be synchronized to the journal before returning response
to client. Default=true
 [journal-type](                                                        | 
the type of journal to use. Default=ASYNCIO
 |  It will use fsync on journal operations. Default=true.
 |  It will use msync/fsync on journal operations. Default=true.
 [large-messages-directory]( "Configuring the server")          |  the directory
to store large messages. Default=data/largemessages
 [management-address]( "Configuring Core Management")   |  the name of the management
address to send management messages to. It is prefixed with "jms.queue" so that JMS clients
can send messages to it.
 [management-notification-address]( "Configuring The Core Management Notification
Address") |  the name of the address that consumers bind to receive management notifications.
diff --git a/docs/user-manual/en/ b/docs/user-manual/en/
index e5266f6..e05578d 100644
--- a/docs/user-manual/en/
+++ b/docs/user-manual/en/
@@ -47,6 +47,11 @@ performance.
 -   If you're running AIO you might be able to get some better
     performance by increasing `journal-max-io`. DO NOT change this
     parameter if you are running NIO.
+-   If you are 100% sure you don't need power failure durability guarantees, 
+    disable `journal-data-sync` and use `NIO` or `MAPPED` journal: 
+    you'll benefit a huge performance boost on writes 
+    with process failure durability guarantees.    
 ## Tuning JMS
diff --git a/docs/user-manual/en/ b/docs/user-manual/en/
index 50d9dc9..323f458 100644
--- a/docs/user-manual/en/
+++ b/docs/user-manual/en/
@@ -74,6 +74,22 @@ implementations. Apache ActiveMQ Artemis ships with two implementations:
     For more information on libaio please see [lib AIO](
     libaio is part of the kernel project.
+-   [Memory mapped](
+    The third implementation uses a file-backed [READ_WRITE](
+    memory mapping against the OS page cache to interface with the file system.
+    This provides extremely good performance (especially under strictly process failure durability
+    almost zero copy (actually *is* the kernel page cache) and zero garbage (from the Java
HEAP perspective) operations and runs 
+    on any platform where there's a Java 4+ runtime.
+    Under power failure durability requirements it will perform at least on par with the
NIO journal with the only 
+    exception of Linux OS with kernel less or equals 2.6, in which the [*msync*](
implementation necessary to ensure 
+    durable writes was different (and slower) from the [*fsync*](
used is case of NIO journal.
+    It benefits by the configuration of OS [huge pages](,
+    in particular when is used a big number of journal files and sizing them as multiple
of the OS page size in bytes.    
 The standard Apache ActiveMQ Artemis core server uses two instances of the journal:
@@ -180,12 +196,13 @@ The message journal is configured using the following attributes in
 -   `journal-type`
-    Valid values are `NIO` or `ASYNCIO`.
+    Valid values are `NIO`, `ASYNCIO` or `MAPPED`.
     Choosing `NIO` chooses the Java NIO journal. Choosing `ASYNCIO` chooses
     the Linux asynchronous IO journal. If you choose `ASYNCIO` but are not
     running Linux or you do not have libaio installed then Apache ActiveMQ Artemis will
     detect this and automatically fall back to using `NIO`.
+    Choosing `MAPPED` chooses the Java Memory Mapped journal.
 -   `journal-sync-transactional`
@@ -302,6 +319,22 @@ The message journal is configured using the following attributes in
 -   `journal-datasync` (default: true)
     This will disable the use of fdatasync on journal writes.
+    When enabled it ensures full power failure durability, otherwise 
+    process failure durability on journal writes (OS guaranteed).
+    This is particular effective for `NIO` and `MAPPED` journals, which rely on 
+     *fsync*/*msync* to force write changes to disk.
+### An important note on disabling `journal-datasync`.
+> Any modern OS guarantees that on process failures (i.e. crash) all the uncommitted changes
+> to the page cache will be flushed to the file system, maintaining coherence between

+> subsequent operations against the same pages and ensuring that no data will be lost.
+> The predictability of the timing of such flushes, in case of a disabled *journal-datasync*,
+> depends on the OS configuration, but without compromising (or relaxing) the process

+> failure durability semantics as described above.
+> Rely on the OS page cache sacrifice the power failure protection, while increasing the

+> effectiveness of the journal operations, capable of exploiting 
+> the read caching and write combining features provided by the OS's kernel page cache
 ### An important note on disabling disk write cache.

View raw message