activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From clebertsuco...@apache.org
Subject [06/15] activemq-artemis git commit: ARTEMIS-1912 big doc refactor
Date Sat, 09 Jun 2018 05:57:16 GMT
http://git-wip-us.apache.org/repos/asf/activemq-artemis/blob/40b66d13/docs/user-manual/en/perf-tuning.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/perf-tuning.md b/docs/user-manual/en/perf-tuning.md
index 81f1f44..3b2d37a 100644
--- a/docs/user-manual/en/perf-tuning.md
+++ b/docs/user-manual/en/perf-tuning.md
@@ -5,269 +5,251 @@ performance.
 
 ## Tuning persistence
 
--   To get the best performance from Apache ActiveMQ Artemis whilst
-    using persistent messages it is recommended that the file store
-    is used.  Apache ActiveMQ Artemis also supports JDBC persistence,
-    but there is a performance cost when persisting to a database vs 
-    local disk.
--   Put the message journal on its own physical volume. If the disk is
-    shared with other processes e.g. transaction co-ordinator, database
-    or other journals which are also reading and writing from it, then
-    this may greatly reduce performance since the disk head may be
-    skipping all over the place between the different files. One of the
-    advantages of an append only journal is that disk head movement is
-    minimised - this advantage is destroyed if the disk is shared. If
-    you're using paging or large messages make sure they're ideally put
-    on separate volumes too.
-
--   Minimum number of journal files. Set `journal-min-files` to a number
-    of files that would fit your average sustainable rate.  This number
-    represents the lower threshold of the journal file pool.
-
--   To set the upper threshold of the journal file pool. (`journal-min-files` being
-    the lower threshold).  Set `journal-pool-files` to a number that represents
-    something near your maximum expected load.  The journal will spill over
-    the pool should it need to, but will shrink back to the upper threshold, 
-    when possible.  This allows reuse of files, without taking up more disk
-    space than required.  If you see new files being created on the journal
-    data directory too often, i.e. lots of data is being persisted, 
-    you need to increase the journal-pool-size, this way the journal would
-    reuse more files instead of creating new data files, increasing performance
-
--   Journal file size. The journal file size should be aligned to the
-    capacity of a cylinder on the disk. The default value 10MiB should
-    be enough on most systems.
-
--   Use AIO journal. If using Linux, try to keep your journal type as
-    AIO. AIO will scale better than Java NIO.
-
--   Tune `journal-buffer-timeout`. The timeout can be increased to
-    increase throughput at the expense of latency.
-
--   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.    
+- To get the best performance from Apache ActiveMQ Artemis whilst using
+  persistent messages it is recommended that the file store is used.  Apache
+  ActiveMQ Artemis also supports JDBC persistence, but there is a performance
+  cost when persisting to a database vs local disk.
+
+- Put the message journal on its own physical volume. If the disk is shared
+  with other processes e.g. transaction co-ordinator, database or other
+  journals which are also reading and writing from it, then this may greatly
+  reduce performance since the disk head may be skipping all over the place
+  between the different files. One of the advantages of an append only journal is
+  that disk head movement is minimised - this advantage is destroyed if the disk
+  is shared. If you're using paging or large messages make sure they're ideally
+  put on separate volumes too.
+
+- Minimum number of journal files. Set `journal-min-files` to a number of files
+  that would fit your average sustainable rate.  This number represents the
+  lower threshold of the journal file pool.
+
+- To set the upper threshold of the journal file pool. (`journal-min-files` being
+  the lower threshold).  Set `journal-pool-files` to a number that represents
+  something near your maximum expected load.  The journal will spill over the
+  pool should it need to, but will shrink back to the upper threshold, when
+  possible.  This allows reuse of files, without taking up more disk space than
+  required.  If you see new files being created on the journal data directory too
+  often, i.e. lots of data is being persisted, you need to increase the
+  journal-pool-size, this way the journal would reuse more files instead of
+  creating new data files, increasing performance
+
+- Journal file size. The journal file size should be aligned to the capacity of
+  a cylinder on the disk. The default value 10MiB should be enough on most
+  systems.
+
+- Use `ASYNCIO` journal. If using Linux, try to keep your journal type as
+  `ASYNCIO`. `ASYNCIO` will scale better than Java NIO.
+
+- Tune `journal-buffer-timeout`. The timeout can be increased to increase
+  throughput at the expense of latency.
+
+- If you're running `ASYNCIO` 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
 
-There are a few areas where some tweaks can be done if you are using the
-JMS API
-
--   Disable message id. Use the `setDisableMessageID()` method on the
-    `MessageProducer` class to disable message ids if you don't need
-    them. This decreases the size of the message and also avoids the
-    overhead of creating a unique ID.
-
--   Disable message timestamp. Use the `setDisableMessageTimeStamp()`
-    method on the `MessageProducer` class to disable message timestamps
-    if you don't need them.
-
--   Avoid `ObjectMessage`. `ObjectMessage` is convenient but it comes at
-    a cost. The body of a `ObjectMessage` uses Java serialization to
-    serialize it to bytes. The Java serialized form of even small
-    objects is very verbose so takes up a lot of space on the wire, also
-    Java serialization is slow compared to custom marshalling
-    techniques. Only use `ObjectMessage` if you really can't use one of
-    the other message types, i.e. if you really don't know the type of
-    the payload until run-time.
-
--   Avoid `AUTO_ACKNOWLEDGE`. `AUTO_ACKNOWLEDGE` mode requires an
-    acknowledgement to be sent from the server for each message received
-    on the client, this means more traffic on the network. If you can,
-    use `DUPS_OK_ACKNOWLEDGE` or use `CLIENT_ACKNOWLEDGE` or a
-    transacted session and batch up many acknowledgements with one
-    acknowledge/commit.
-
--   Avoid durable messages. By default JMS messages are durable. If you
-    don't really need durable messages then set them to be non-durable.
-    Durable messages incur a lot more overhead in persisting them to
-    storage.
-
--   Batch many sends or acknowledgements in a single transaction.
-    Apache ActiveMQ Artemis will only require a network round trip on the commit, not
-    on every send or acknowledgement.
+There are a few areas where some tweaks can be done if you are using the JMS
+API
+
+- Disable message id. Use the `setDisableMessageID()` method on the
+  `MessageProducer` class to disable message ids if you don't need them. This
+  decreases the size of the message and also avoids the overhead of creating a
+  unique ID.
+
+- Disable message timestamp. Use the `setDisableMessageTimeStamp()` method on
+  the `MessageProducer` class to disable message timestamps if you don't need
+  them.
+
+- Avoid `ObjectMessage`. `ObjectMessage` is convenient but it comes at a cost.
+  The body of a `ObjectMessage` uses Java serialization to serialize it to
+  bytes. The Java serialized form of even small objects is very verbose so takes
+  up a lot of space on the wire, also Java serialization is slow compared to
+  custom marshalling techniques. Only use `ObjectMessage` if you really can't use
+  one of the other message types, i.e. if you really don't know the type of the
+  payload until run-time.
+
+- Avoid `AUTO_ACKNOWLEDGE`. `AUTO_ACKNOWLEDGE` mode requires an acknowledgement
+  to be sent from the server for each message received on the client, this
+  means more traffic on the network. If you can, use `DUPS_OK_ACKNOWLEDGE` or use
+  `CLIENT_ACKNOWLEDGE` or a transacted session and batch up many acknowledgements
+  with one acknowledge/commit.
+
+- Avoid durable messages. By default JMS messages are durable. If you don't
+  really need durable messages then set them to be non-durable.  Durable
+  messages incur a lot more overhead in persisting them to storage.
+
+- Batch many sends or acknowledgements in a single transaction.  Apache
+  ActiveMQ Artemis will only require a network round trip on the commit, not on
+  every send or acknowledgement.
 
 ## Other Tunings
 
-There are various other places in Apache ActiveMQ Artemis where we can perform some
-tuning:
-
--   Use Asynchronous Send Acknowledgements. If you need to send durable
-    messages non transactionally and you need a guarantee that they have
-    reached the server by the time the call to send() returns, don't set
-    durable messages to be sent blocking, instead use asynchronous send
-    acknowledgements to get your acknowledgements of send back in a
-    separate stream, see [Guarantees of sends and commits](send-guarantees.md)
-    for more information on this.
-
--   Use pre-acknowledge mode. With pre-acknowledge mode, messages are
-    acknowledged `before` they are sent to the client. This reduces the
-    amount of acknowledgement traffic on the wire. For more information
-    on this, see [Extra Acknowledge Modes](pre-acknowledge.md).
-
--   Disable security. You may get a small performance boost by disabling
-    security by setting the `security-enabled` parameter to `false` in
-    `broker.xml`.
-
--   Disable persistence. If you don't need message persistence, turn it
-    off altogether by setting `persistence-enabled` to false in
-    `broker.xml`.
-
--   Sync transactions lazily. Setting `journal-sync-transactional` to
-    `false` in `broker.xml` can give you better
-    transactional persistent performance at the expense of some
-    possibility of loss of transactions on failure. See  [Guarantees of sends and commits](send-guarantees.md)
-    for more information.
-
--   Sync non transactional lazily. Setting
-    `journal-sync-non-transactional` to `false` in
-    `broker.xml` can give you better non-transactional
-    persistent performance at the expense of some possibility of loss of
-    durable messages on failure. See  [Guarantees of sends and commits](send-guarantees.md)
-    for more information.
-
--   Send messages non blocking. Setting `block-on-durable-send` and
-    `block-on-non-durable-send` to `false` in the jms config (if
-    you're using JMS and JNDI) or directly on the ServerLocator. This
-    means you don't have to wait a whole network round trip for every
-    message sent. See  [Guarantees of sends and commits](send-guarantees.md)
-    for more information.
-
--   If you have very fast consumers, you can increase
-    consumer-window-size. This effectively disables consumer flow
-    control.
-
--   Use the core API not JMS. Using the JMS API you will have slightly
-    lower performance than using the core API, since all JMS operations
-    need to be translated into core operations before the server can
-    handle them. If using the core API try to use methods that take
-    `SimpleString` as much as possible. `SimpleString`, unlike
-    java.lang.String does not require copying before it is written to
-    the wire, so if you re-use `SimpleString` instances between calls
-    then you can avoid some unnecessary copying.
-    
--   If using frameworks like Spring, configure destinations permanently broker side
-    and enable `destinationCache` on the client side. 
-    See the [Setting The Destination Cache](using-jms.md)
-                                                          for more information on this.
+There are various other places in Apache ActiveMQ Artemis where we can perform
+some tuning:
+
+- Use Asynchronous Send Acknowledgements. If you need to send durable messages
+  non transactionally and you need a guarantee that they have reached the
+  server by the time the call to send() returns, don't set durable messages to be
+  sent blocking, instead use asynchronous send acknowledgements to get your
+  acknowledgements of send back in a separate stream, see [Guarantees of sends
+  and commits](send-guarantees.md) for more information on this.
+
+- Use pre-acknowledge mode. With pre-acknowledge mode, messages are
+  acknowledged `before` they are sent to the client. This reduces the amount of
+  acknowledgement traffic on the wire. For more information on this, see [Extra
+  Acknowledge Modes](pre-acknowledge.md).
+
+- Disable security. You may get a small performance boost by disabling security
+  by setting the `security-enabled` parameter to `false` in `broker.xml`.
+
+- Disable persistence. If you don't need message persistence, turn it off
+  altogether by setting `persistence-enabled` to false in `broker.xml`.
+
+- Sync transactions lazily. Setting `journal-sync-transactional` to `false` in
+  `broker.xml` can give you better transactional persistent performance at the
+  expense of some possibility of loss of transactions on failure. See
+  [Guarantees of sends and commits](send-guarantees.md) for more information.
+
+- Sync non transactional lazily. Setting `journal-sync-non-transactional` to
+  `false` in `broker.xml` can give you better non-transactional persistent
+  performance at the expense of some possibility of loss of durable messages on
+  failure. See  [Guarantees of sends and commits](send-guarantees.md) for more
+  information.
+
+- Send messages non blocking. Setting `block-on-durable-send` and
+  `block-on-non-durable-send` to `false` in the jms config (if you're using JMS
+  and JNDI) or directly on the ServerLocator. This means you don't have to wait a
+  whole network round trip for every message sent. See  [Guarantees of sends and
+  commits](send-guarantees.md) for more information.
+
+- If you have very fast consumers, you can increase consumer-window-size. This
+  effectively disables consumer flow control.
+
+- Use the core API not JMS. Using the JMS API you will have slightly lower
+  performance than using the core API, since all JMS operations need to be
+  translated into core operations before the server can handle them. If using the
+  core API try to use methods that take `SimpleString` as much as possible.
+  `SimpleString`, unlike java.lang.String does not require copying before it is
+  written to the wire, so if you re-use `SimpleString` instances between calls
+  then you can avoid some unnecessary copying.
+  
+- If using frameworks like Spring, configure destinations permanently broker
+  side and enable `destinationCache` on the client side.  See the [Setting The
+  Destination Cache](using-jms.md) for more information on this.
 
 ## Tuning Transport Settings
 
--   TCP buffer sizes. If you have a fast network and fast machines you
-    may get a performance boost by increasing the TCP send and receive
-    buffer sizes. See the [Configuring the Transport](configuring-transports.md)
-    for more information on this.
-
-    > **Note**
-    >
-    > Note that some operating systems like later versions of Linux
-    > include TCP auto-tuning and setting TCP buffer sizes manually can
-    > prevent auto-tune from working and actually give you worse
-    > performance!
-
--   Increase limit on file handles on the server. If you expect a lot of
-    concurrent connections on your servers, or if clients are rapidly
-    opening and closing connections, you should make sure the user
-    running the server has permission to create sufficient file handles.
-
-    This varies from operating system to operating system. On Linux
-    systems you can increase the number of allowable open file handles
-    in the file `/etc/security/limits.conf` e.g. add the lines
-
-        serveruser     soft    nofile  20000
-        serveruser     hard    nofile  20000
-
-    This would allow up to 20000 file handles to be open by the user
-    `serveruser`.
-
--   Use `batch-delay` and set `direct-deliver` to false for the best
-    throughput for very small messages. Apache ActiveMQ Artemis comes with a
-    preconfigured connector/acceptor pair (`netty-throughput`) in
-    `broker.xml` and JMS connection factory
-    (`ThroughputConnectionFactory`) in `activemq-jms.xml`which can be
-    used to give the very best throughput, especially for small
-    messages. See the [Configuring the Transport](configuring-transports.md)
-    for more information on this.
+- TCP buffer sizes. If you have a fast network and fast machines you may get a
+  performance boost by increasing the TCP send and receive buffer sizes. See
+  the [Configuring the Transport](configuring-transports.md) for more information
+  on this.
+
+  > **Note:**
+  >
+  > Note that some operating systems like later versions of Linux include TCP
+  > auto-tuning and setting TCP buffer sizes manually can prevent auto-tune
+  > from working and actually give you worse performance!
+
+- Increase limit on file handles on the server. If you expect a lot of
+  concurrent connections on your servers, or if clients are rapidly opening and
+  closing connections, you should make sure the user running the server has
+  permission to create sufficient file handles.
+
+  This varies from operating system to operating system. On Linux systems you
+  can increase the number of allowable open file handles in the file
+  `/etc/security/limits.conf` e.g. add the lines
+
+  ```
+  serveruser   soft  nofile  20000
+  serveruser   hard  nofile  20000
+  ```
+
+  This would allow up to 20000 file handles to be open by the user
+  `serveruser`.
+
+- Use `batch-delay` and set `direct-deliver` to false for the best throughput
+  for very small messages. Apache ActiveMQ Artemis comes with a preconfigured
+  connector/acceptor pair (`netty-throughput`) in `broker.xml` and JMS connection
+  factory (`ThroughputConnectionFactory`) in `activemq-jms.xml`which can be used
+  to give the very best throughput, especially for small messages. See the
+  [Configuring the Transport](configuring-transports.md) for more information on
+  this.
 
 ## Tuning the VM
 
-We highly recommend you use the latest Java JVM for the best
-performance. We test internally using the Sun JVM, so some of these
-tunings won't apply to JDKs from other providers (e.g. IBM or JRockit)
-
--   Garbage collection. For smooth server operation we recommend using a
-    parallel garbage collection algorithm, e.g. using the JVM argument
-    `-XX:+UseParallelOldGC` on Sun JDKs.
-
--   Memory settings. Give as much memory as you can to the server.
-    Apache ActiveMQ Artemis can run in low memory by using paging (described in [Paging](paging.md)) but
-    if it can run with all queues in RAM this will improve performance.
-    The amount of memory you require will depend on the size and number
-    of your queues and the size and number of your messages. Use the JVM
-    arguments `-Xms` and `-Xmx` to set server available RAM. We
-    recommend setting them to the same high value.
-    
-    When under periods of high load, it is likely that Artemis will be generating 
-    and destroying lots of objects. This can result in a build up of stale objects. 
-    To reduce the chance of running out of memory and causing a full GC 
-    (which may introduce pauses and unintentional behaviour), it is recommended that the 
-    max heap size (`-Xmx`) for the JVM is set at least to 5 x the `global-max-size` of the broker.
-    As an example, in a situation where the broker is under high load and running 
-    with a `global-max-size` of 1GB, it is recommended the the max heap size is set to 5GB.  
-
--   Aggressive options. Different JVMs provide different sets of JVM
-    tuning parameters, for the Sun Hotspot JVM the full list of options
-    is available
-    [here](http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html).
-    We recommend at least using `-XX:+AggressiveOpts`.
-    You may get some mileage with the other tuning parameters depending
-    on your OS platform and application usage patterns.
+We highly recommend you use the latest Java JVM for the best performance. We
+test internally using the Sun JVM, so some of these tunings won't apply to JDKs
+from other providers (e.g. IBM or JRockit)
+
+- Garbage collection. For smooth server operation we recommend using a parallel
+  garbage collection algorithm, e.g. using the JVM argument
+  `-XX:+UseParallelOldGC` on Sun JDKs.
+
+- Memory settings. Give as much memory as you can to the server.  Apache
+  ActiveMQ Artemis can run in low memory by using paging (described in
+  [Paging](paging.md)) but if it can run with all queues in RAM this will improve
+  performance.  The amount of memory you require will depend on the size and
+  number of your queues and the size and number of your messages. Use the JVM
+  arguments `-Xms` and `-Xmx` to set server available RAM. We recommend setting
+  them to the same high value.
+  
+  When under periods of high load, it is likely that Artemis will be generating
+  and destroying lots of objects. This can result in a build up of stale objects.
+  To reduce the chance of running out of memory and causing a full GC (which may
+  introduce pauses and unintentional behaviour), it is recommended that the max
+  heap size (`-Xmx`) for the JVM is set at least to 5 x the `global-max-size` of
+  the broker.  As an example, in a situation where the broker is under high load
+  and running with a `global-max-size` of 1GB, it is recommended the the max heap
+  size is set to 5GB.  
+
+- Aggressive options. Different JVMs provide different sets of JVM tuning
+  parameters, for the Sun Hotspot JVM the full list of options is available
+  [here](http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html).
+  We recommend at least using `-XX:+AggressiveOpts`.  You may get some mileage
+  with the other tuning parameters depending on your OS platform and application
+  usage patterns.
 
 ## Avoiding Anti-Patterns
 
--   Re-use connections / sessions / consumers / producers. Probably the
-    most common messaging anti-pattern we see is users who create a new
-    connection/session/producer for every message they send or every
-    message they consume. This is a poor use of resources. These objects
-    take time to create and may involve several network round trips.
-    Always re-use them.
-
-    > **Note**
-    >
-    > Some popular libraries such as the Spring JMS Template are known
-    > to use these anti-patterns. If you're using Spring JMS Template
-    > and you're getting poor performance you know why. Don't blame
-    > Apache ActiveMQ Artemis! The Spring JMS Template can only safely be used in an
-    > app server which caches JMS sessions (e.g. using JCA), and only
-    > then for sending messages. It cannot be safely be used for
-    > synchronously consuming messages, even in an app server.
-
--   Avoid fat messages. Verbose formats such as XML take up a lot of
-    space on the wire and performance will suffer as result. Avoid XML
-    in message bodies if you can.
-
--   Don't create temporary queues for each request. This common
-    anti-pattern involves the temporary queue request-response pattern.
-    With the temporary queue request-response pattern a message is sent
-    to a target and a reply-to header is set with the address of a local
-    temporary queue. When the recipient receives the message they
-    process it then send back a response to the address specified in the
-    reply-to. A common mistake made with this pattern is to create a new
-    temporary queue on each message sent. This will drastically reduce
-    performance. Instead the temporary queue should be re-used for many
-    requests.
-
--   Don't use Message-Driven Beans for the sake of it. As soon as you
-    start using MDBs you are greatly increasing the codepath for each
-    message received compared to a straightforward message consumer,
-    since a lot of extra application server code is executed. Ask
-    yourself do you really need MDBs? Can you accomplish the same task
-    using just a normal message consumer?
+- Re-use connections / sessions / consumers / producers. Probably the most
+  common messaging anti-pattern we see is users who create a new
+  connection/session/producer for every message they send or every message they
+  consume. This is a poor use of resources. These objects take time to create and
+  may involve several network round trips.  Always re-use them.
+
+  > **Note:**
+  >
+  > Some popular libraries such as the Spring JMS Template are known to use
+  > these anti-patterns. If you're using Spring JMS Template and you're getting
+  > poor performance you know why. Don't blame Apache ActiveMQ Artemis! The
+  > Spring JMS Template can only safely be used in an app server which caches
+  > JMS sessions (e.g. using JCA), and only then for sending messages. It
+  > cannot be safely be used for synchronously consuming messages, even in an
+  > app server.
+
+- Avoid fat messages. Verbose formats such as XML take up a lot of space on the
+  wire and performance will suffer as result. Avoid XML in message bodies if
+  you can.
+
+- Don't create temporary queues for each request. This common anti-pattern
+  involves the temporary queue request-response pattern.  With the temporary
+  queue request-response pattern a message is sent to a target and a reply-to
+  header is set with the address of a local temporary queue. When the recipient
+  receives the message they process it then send back a response to the address
+  specified in the reply-to. A common mistake made with this pattern is to create
+  a new temporary queue on each message sent. This will drastically reduce
+  performance. Instead the temporary queue should be re-used for many requests.
+
+- Don't use Message-Driven Beans for the sake of it. As soon as you start using
+  MDBs you are greatly increasing the codepath for each message received
+  compared to a straightforward message consumer, since a lot of extra
+  application server code is executed. Ask yourself do you really need MDBs? Can
+  you accomplish the same task using just a normal message consumer?
 
 ## Troubleshooting
 
@@ -275,17 +257,30 @@ tunings won't apply to JDKs from other providers (e.g. IBM or JRockit)
 
 In certain situations UDP used on discovery may not work. Typical situations are:
 
-1. The nodes are behind a firewall. If your nodes are on different machines then it is possible that the firewall is blocking the multicasts. you can test this by disabling the firewall for each node or adding the appropriate rules.
-2. You are using a home network or are behind a gateway. Typically home networks will redirect any UDP traffic to the Internet Service Provider which is then either dropped by the ISP or just lost. To fix this you will need to add a route to the firewall/gateway that will redirect any multicast traffic back on to the local network instead.
-3. All the nodes are in one machine. If this is the case then it is a similar problem to point 2 and the same solution should fix it. Alternatively you could add a multicast route to the loopback interface. On linux the command would be:
-```sh
-# you should run this as root
-route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
-```
- This will redirect any traffic directed to the 224.0.0.0 to the loopback interface. This will also work if you have no network at all.
-
-   * on Mac OS X, the command is slightly different:
-```sh
-sudo route add 224.0.0.0 127.0.0.1 -netmask 240.0.0.0
-```
+1. The nodes are behind a firewall. If your nodes are on different machines
+   then it is possible that the firewall is blocking the multicasts. you can
+   test this by disabling the firewall for each node or adding the appropriate
+   rules.
+2. You are using a home network or are behind a gateway. Typically home
+   networks will redirect any UDP traffic to the Internet Service Provider
+   which is then either dropped by the ISP or just lost. To fix this you will need
+   to add a route to the firewall/gateway that will redirect any multicast traffic
+   back on to the local network instead.
+3. All the nodes are in one machine. If this is the case then it is a similar
+   problem to point 2 and the same solution should fix it. Alternatively you
+   could add a multicast route to the loopback interface. On linux the command
+   would be:
+
+   ```sh
+   # you should run this as root
+   route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
+   ```
+   
+   This will redirect any traffic directed to the 224.0.0.0 to the loopback
+   interface. This will also work if you have no network at all. On Mac OS X, the
+   command is slightly different:
+
+   ```sh
+   sudo route add 224.0.0.0 127.0.0.1 -netmask 240.0.0.0
+   ```
 

http://git-wip-us.apache.org/repos/asf/activemq-artemis/blob/40b66d13/docs/user-manual/en/persistence.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/persistence.md b/docs/user-manual/en/persistence.md
index 00159e4..b0b253b 100644
--- a/docs/user-manual/en/persistence.md
+++ b/docs/user-manual/en/persistence.md
@@ -59,7 +59,7 @@ 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
+This journal option 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 Installing AIO section.
 
@@ -69,53 +69,53 @@ systems: ext2, ext3, ext4, jfs, xfs and NFSV4.
 For more information on libaio please see [lib AIO](libaio.md).
 
 libaio is part of the kernel project.
-    
+  
 ### [Memory mapped](https://en.wikipedia.org/wiki/Memory-mapped_file)
 
 The third implementation uses a file-backed [READ_WRITE](https://docs.oracle.com/javase/8/docs/api/java/nio/channels/FileChannel.MapMode.html#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 requirements), 
 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*](https://docs.oracle.com/javase/8/docs/api/java/nio/MappedByteBuffer.html#force%28%29)) implementation necessary to ensure 
 durable writes was different (and slower) from the [*fsync*](https://docs.oracle.com/javase/8/docs/api/java/nio/channels/FileChannel.html#force%28boolean%29) used is case of NIO journal.
-    
+  
 It benefits by the configuration of OS [huge pages](https://en.wikipedia.org/wiki/Page_%28computer_memory%29),
-in particular when is used a big number of journal files and sizing them as multiple of the OS page size in bytes.    
+in particular when is used a big number of journal files and sizing them as multiple of the OS page size in bytes.  
 
 ### Standard Files
 
 The standard Apache ActiveMQ Artemis core server uses two instances of the journal:
 
--   Bindings 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.
+  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 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 `activemq-bindings`. Each
-    file has a `bindings` extension. File size is `1048576`, and it is
-    located at the bindings folder.
+  The files on this journal are prefixed as `activemq-bindings`. Each
+  file has a `bindings` extension. File size is `1048576`, and it is
+  located at the bindings folder.
 
--   Message journal.
+- Message journal.
 
-    This journal instance stores all message related data, including the
-    message themselves and also duplicate-id caches.
+  This journal instance stores all message related data, including the
+  message themselves and also duplicate-id caches.
 
-    By default Apache ActiveMQ Artemis 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.
+  By default Apache ActiveMQ Artemis 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 `activemq-data`. Each file
-    has a `amq` extension. File size is by the default `10485760`
-    (configurable), and it is located at the journal folder.
+  The files on this journal are prefixed as `activemq-data`. Each file
+  has a `amq` extension. File size is by the default `10485760`
+  (configurable), and it is located at the journal folder.
 
 For large messages, Apache ActiveMQ Artemis persists them outside the message journal.
 This is discussed in [Large Messages](large-messages.md).
@@ -132,17 +132,17 @@ the broker for Zero Persistence section.
 The bindings journal is configured using the following attributes in
 `broker.xml`
 
--   `bindings-directory`
+- `bindings-directory`
 
-    This is the directory in which the bindings journal lives. The
-    default value is `data/bindings`.
+  This is the directory in which the bindings journal lives. The
+  default value is `data/bindings`.
 
--   `create-bindings-dir`
+- `create-bindings-dir`
 
-    If this is set to `true` then the bindings directory will be
-    automatically created at the location specified in
-    `bindings-directory` if it does not already exist. The default value
-    is `true`
+  If this is set to `true` then the bindings directory will be
+  automatically created at the location specified in
+  `bindings-directory` if it does not already exist. The default value
+  is `true`
 
 #### Configuring the jms journal
 
@@ -153,159 +153,158 @@ The jms config shares its configuration with the bindings journal.
 The message journal is configured using the following attributes in
 `broker.xml`
 
--   `journal-directory`
+- `journal-directory`
 
-    This is the directory in which the message journal lives. The
-    default value is `data/journal`.
+  This is the directory in which the message journal lives. The
+  default value is `data/journal`.
 
-    For the best performance, we recommend the journal is located on its
-    own physical volume in order to minimise disk head movement. If the
-    journal is on a volume which is shared with other processes which
-    might be writing other files (e.g. 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.
+  For the best performance, we recommend the journal is located on its
+  own physical volume in order to minimise disk head movement. If the
+  journal is on a volume which is shared with other processes which
+  might be writing other files (e.g. 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 the message journal is stored on a SAN we recommend each
-    journal instance that is stored on the SAN is given its own LUN
-    (logical unit).
+  When the message journal is stored on a SAN we recommend each
+  journal instance that is stored on the SAN is given its own LUN
+  (logical unit).
 
--   `create-journal-dir`
+- `create-journal-dir`
 
-    If this is set to `true` then 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`
+  If this is set to `true` then 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`
 
--   `journal-type`
+- `journal-type`
 
-    Valid values are `NIO`, `ASYNCIO` or `MAPPED`.
+  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.
+  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`
+- `journal-sync-transactional`
 
-    If this is set to true then Apache ActiveMQ Artemis will make sure all transaction
-    data is flushed to disk on transaction boundaries (commit, prepare
-    and rollback). The default value is `true`.
+  If this is set to true then Apache ActiveMQ Artemis will make sure all transaction
+  data is flushed to disk on transaction boundaries (commit, prepare
+  and rollback). The default value is `true`.
 
--   `journal-sync-non-transactional`
+- `journal-sync-non-transactional`
 
-    If this is set to true then Apache ActiveMQ Artemis will make sure non
-    transactional message data (sends and acknowledgements) are flushed
-    to disk each time. The default value for this is `true`.
+  If this is set to true then Apache ActiveMQ Artemis will make sure non
+  transactional message data (sends and acknowledgements) are flushed
+  to disk each time. The default value for this is `true`.
 
--   `journal-file-size`
+- `journal-file-size`
 
-    The size of each journal file in bytes. The default value for this
-    is `10485760` bytes (10MiB).
+  The size of each journal file in bytes. The default value for this
+  is `10485760` bytes (10MiB).
 
--   `journal-min-files`
+- `journal-min-files`
 
-    The minimum number of files the journal will maintain. When Apache ActiveMQ Artemis
-    starts and there is no initial message data, Apache ActiveMQ Artemis will
-    pre-create `journal-min-files` number of files.
+  The minimum number of files the journal will maintain. When Apache ActiveMQ Artemis
+  starts and there is no initial message data, Apache ActiveMQ Artemis will
+  pre-create `journal-min-files` number of files.
 
-    Creating journal files and filling them with padding is a fairly
-    expensive operation and we want to minimise doing this at run-time
-    as files get filled. By pre-creating files, as one is filled the
-    journal can immediately resume with the next one without pausing to
-    create it.
+  Creating journal files and filling them with padding is a fairly
+  expensive operation and we want to minimise doing this at run-time
+  as files get filled. By pre-creating files, as one is filled the
+  journal can immediately resume with the next one without pausing to
+  create it.
 
-    Depending on how much data you expect your queues to contain at
-    steady state you should tune this number of files to match that
-    total amount of data.
+  Depending on how much data you expect your queues to contain at
+  steady state you should tune this number of files to match that
+  total amount of data.
 
--   `journal-pool-files`
+- `journal-pool-files`
 
-    The system will create as many files as needed however when reclaiming files
-    it will shrink back to the `journal-pool-files`.
+  The system will create as many files as needed however when reclaiming files
+  it will shrink back to the `journal-pool-files`.
 
-    The default to this parameter is -1, meaning it will never delete files on the journal once created.
+  The default to this parameter is -1, meaning it will never delete files on the journal once created.
 
-    Notice that the system can't grow infinitely as you are still required to use paging for destinations that can
-    grow indefinitely.
+  Notice that the system can't grow infinitely as you are still required to use paging for destinations that can
+  grow indefinitely.
 
-    Notice: in case you get too many files you can use [compacting](tools.md).
+  Notice: in case you get too many files you can use [compacting](data-tools.md).
 
--   `journal-max-io`
+- `journal-max-io`
 
-    Write requests are queued up before being submitted to the system
-    for execution. This parameter 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.
+  Write requests are queued up before being submitted to the system
+  for execution. This parameter 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 equal to `1`
+  When using NIO, this value should always be equal to `1`
 
-    When using AIO, the default should be `500`.
+  When using ASYNCIO, the default should be `500`.
 
-    The system maintains different defaults for this parameter depending
-    on whether it's NIO or AIO (default for NIO is 1, default for AIO is
-    500)
+  The system maintains different defaults for this parameter depending
+  on whether it's NIO or ASYNCIO (default for NIO is 1, default for ASYNCIO is
+  500)
 
-    There is a limit and the total max AIO can't be higher than what is
-    configured at the OS level (/proc/sys/fs/aio-max-nr) usually at
-    65536.
+  There is a limit and the total max ASYNCIO can't be higher than what is
+  configured at the OS level (/proc/sys/fs/aio-max-nr) usually at
+  65536.
 
--   `journal-buffer-timeout`
+- `journal-buffer-timeout`
 
-    Instead of flushing on every write that requires a flush, we
-    maintain an internal buffer, and flush the entire buffer either when
-    it is full, or when a timeout expires, whichever is sooner. This is
-    used for both NIO and AIO and allows the system to scale better with
-    many concurrent writes that require flushing.
+  Instead of flushing on every write that requires a flush, we
+  maintain an internal buffer, and flush the entire buffer either when
+  it is full, or when a timeout expires, whichever is sooner. This is
+  used for both NIO and ASYNCIO and allows the system to scale better with
+  many concurrent writes that require flushing.
 
-    This parameter controls the timeout at which the buffer will be
-    flushed if it hasn't filled already. AIO can typically cope with a
-    higher flush rate than NIO, so the system maintains different
-    defaults for both NIO and AIO (default for NIO is 3333333
-    nanoseconds - 300 times per second, default for AIO is 500000
-    nanoseconds - ie. 2000 times per second).
+  This parameter controls the timeout at which the buffer will be
+  flushed if it hasn't filled already. ASYNCIO can typically cope with a
+  higher flush rate than NIO, so the system maintains different
+  defaults for both NIO and ASYNCIO (default for NIO is 3333333
+  nanoseconds - 300 times per second, default for ASYNCIO is 500000
+  nanoseconds - ie. 2000 times per second).
 
-    > **Note**
-    >
-    > By increasing the timeout, you may be able to increase system
-    > throughput at the expense of latency, the default parameters are
-    > chosen to give a reasonable balance between throughput and
-    > latency.
+  > **Note:**
+  >
+  > By increasing the timeout, you may be able to increase system
+  > throughput at the expense of latency, the default parameters are
+  > chosen to give a reasonable balance between throughput and
+  > latency.
 
--   `journal-buffer-size`
+- `journal-buffer-size`
 
-    The size of the timed buffer on AIO. The default value is `490KiB`.
+  The size of the timed buffer on ASYNCIO. The default value is `490KiB`.
 
--   `journal-compact-min-files`
+- `journal-compact-min-files`
 
-    The minimal number of files before we can consider compacting the
-    journal. The compacting algorithm won't start until you have at
-    least `journal-compact-min-files`
+  The minimal number of files before we can consider compacting the
+  journal. The compacting algorithm won't start until you have at
+  least `journal-compact-min-files`
 
-    Setting this to 0 will disable the feature to compact completely.
-    This could be dangerous though as the journal could grow indefinitely.
-    Use it wisely!
+  Setting this to 0 will disable the feature to compact completely.
+  This could be dangerous though as the journal could grow indefinitely.
+  Use it wisely!
 
+  The default for this parameter is `10`
 
-    The default for this parameter is `10`
+- `journal-compact-percentage`
 
--   `journal-compact-percentage`
+  The threshold to start compacting. When less than this percentage is
+  considered live data, we start compacting. Note also that compacting
+  won't kick in until you have at least `journal-compact-min-files`
+  data files on the journal
 
-    The threshold to start compacting. When less than this percentage is
-    considered live data, we start compacting. Note also that compacting
-    won't kick in until you have at least `journal-compact-min-files`
-    data files on the journal
-
-    The default for this parameter is `30`
-    
--   `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.
+  The default for this parameter is `30`
+  
+- `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.
 
 #### Note on disabling `journal-datasync`
 
@@ -362,9 +361,9 @@ The message journal is configured using the following attributes in
 
 The Java NIO journal gives great performance, but If you are running
 Apache ActiveMQ Artemis using Linux Kernel 2.6 or later, we highly recommend you use
-the `AIO` journal for the very best persistence performance.
+the `ASYNCIO` journal for the very best persistence performance.
 
-It's not possible to use the AIO journal under other operating systems
+It's not possible to use the ASYNCIO journal under other operating systems
 or earlier versions of the Linux kernel.
 
 If you are running Linux kernel 2.6 or later and don't already have
@@ -372,11 +371,15 @@ If you are running Linux kernel 2.6 or later and don't already have
 
 Using yum, (e.g. on Fedora or Red Hat Enterprise Linux):
 
-    yum install libaio
+```sh
+yum install libaio
+```
 
 Using aptitude, (e.g. on Ubuntu or Debian system):
 
-    apt-get install libaio
+```sh
+apt-get install libaio
+```
 
 ## JDBC Persistence
 
@@ -423,50 +426,50 @@ To configure Apache ActiveMQ Artemis to use a database for persisting messages a
 </store>
 ```
 
--   `jdbc-connection-url`
+- `jdbc-connection-url`
 
-    The full JDBC connection URL for your database server.  The connection url should include all configuration parameters and database name.  Note: When configuring the server using the XML configuration files please ensure to escape any illegal chars; "&" for example, is typical in JDBC connection url and should be escaped to "&amp;".
+  The full JDBC connection URL for your database server.  The connection url should include all configuration parameters and database name.  **Note:** When configuring the server using the XML configuration files please ensure to escape any illegal chars; "&" for example, is typical in JDBC connection url and should be escaped to "&amp;".
 
--   `bindings-table-name`
+- `bindings-table-name`
 
-    The name of the table in which bindings data will be persisted for the ActiveMQ Artemis server.  Specifying table names allows users to share single database amongst multiple servers, without interference.
+  The name of the table in which bindings data will be persisted for the ActiveMQ Artemis server.  Specifying table names allows users to share single database amongst multiple servers, without interference.
 
--   `message-table-name`
+- `message-table-name`
 
-    The name of the table in which bindings data will be persisted for the ActiveMQ Artemis server.  Specifying table names allows users to share single database amongst multiple servers, without interference.
+  The name of the table in which bindings data will be persisted for the ActiveMQ Artemis server.  Specifying table names allows users to share single database amongst multiple servers, without interference.
 
--   `large-message-table-name`
+- `large-message-table-name`
 
-    The name of the table in which messages and related data will be persisted for the ActiveMQ Artemis server.  Specifying table names allows users to share single database amongst multiple servers, without interference.
-    
--   `page-store-table-name`
+  The name of the table in which messages and related data will be persisted for the ActiveMQ Artemis server.  Specifying table names allows users to share single database amongst multiple servers, without interference.
+  
+- `page-store-table-name`
 
-    The name of the table to house the page store directory information.  Note that each address will have it's own page table which will use this name appended with a unique id of up to 20 characters.
+  The name of the table to house the page store directory information.  Note that each address will have it's own page table which will use this name appended with a unique id of up to 20 characters.
 
--   `node-manager-store-table-name`
+- `node-manager-store-table-name`
 
-    The name of the table in which the HA Shared Store locks (ie live and backup) and HA related data will be persisted for the ActiveMQ Artemis server.  Specifying table names allows users to share single database amongst multiple servers, without interference.
-    Each Shared Store live/backup pairs must use the same table name and isn't supported to share the same table between multiple (and unrelated) live/backup pairs.
+  The name of the table in which the HA Shared Store locks (ie live and backup) and HA related data will be persisted for the ActiveMQ Artemis server.  Specifying table names allows users to share single database amongst multiple servers, without interference.
+  Each Shared Store live/backup pairs must use the same table name and isn't supported to share the same table between multiple (and unrelated) live/backup pairs.
 
--   `jdbc-driver-class-name`
+- `jdbc-driver-class-name`
 
-    The fully qualified class name of the desired database Driver.
+  The fully qualified class name of the desired database Driver.
 
--   `jdbc-network-timeout`
+- `jdbc-network-timeout`
 
-    The JDBC network connection timeout in milliseconds. The default value
-    is 20000 milliseconds (ie 20 seconds).
-    When using a shared store it is recommended to set it less then or equal to `jdbc-lock-expiration`.
+  The JDBC network connection timeout in milliseconds. The default value
+  is 20000 milliseconds (ie 20 seconds).
+  When using a shared store it is recommended to set it less then or equal to `jdbc-lock-expiration`.
     
--   `jdbc-lock-renew-period`
+- `jdbc-lock-renew-period`
 
-    The period in milliseconds of the keep alive service of a JDBC lock. The default value
-    is 2000 milliseconds (ie 2 seconds).
-    
--   `jdbc-lock-expiration`
+  The period in milliseconds of the keep alive service of a JDBC lock. The default value
+  is 2000 milliseconds (ie 2 seconds).
+  
+- `jdbc-lock-expiration`
 
-    The time in milliseconds a JDBC lock is considered valid without keeping it alive. The default value
-    is 20000 milliseconds (ie 20 seconds).
+  The time in milliseconds a JDBC lock is considered valid without keeping it alive. The default value
+  is 20000 milliseconds (ie 20 seconds).
 
 -   `jdbc-journal-sync-period`
 

http://git-wip-us.apache.org/repos/asf/activemq-artemis/blob/40b66d13/docs/user-manual/en/pre-acknowledge.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/pre-acknowledge.md b/docs/user-manual/en/pre-acknowledge.md
index d328d8b..fc7942a 100644
--- a/docs/user-manual/en/pre-acknowledge.md
+++ b/docs/user-manual/en/pre-acknowledge.md
@@ -2,11 +2,11 @@
 
 JMS specifies 3 acknowledgement modes:
 
--   `AUTO_ACKNOWLEDGE`
+- `AUTO_ACKNOWLEDGE`
 
--   `CLIENT_ACKNOWLEDGE`
+- `CLIENT_ACKNOWLEDGE`
 
--   `DUPS_OK_ACKNOWLEDGE`
+- `DUPS_OK_ACKNOWLEDGE`
 
 Apache ActiveMQ Artemis supports two additional modes: `PRE_ACKNOWLEDGE` and
 `INDIVIDUAL_ACKNOWLEDGE`
@@ -32,7 +32,7 @@ update messages. With these messages it might be reasonable to lose a
 message in event of crash, since the next price update message will
 arrive soon, overriding the previous price.
 
-> **Note**
+> **Note:**
 >
 > Please note, that if you use pre-acknowledge mode, then you will lose
 > transactional semantics for messages being consumed, since clearly
@@ -67,7 +67,7 @@ acknowledge mode with `ActiveMQJMSConstants.INDIVIDUAL_ACKNOWLEDGE`.
 Individual ACK inherits all the semantics from Client Acknowledge, with
 the exception the message is individually acked.
 
-> **Note**
+> **Note:**
 >
 > Please note, that to avoid confusion on MDB processing, Individual
 > ACKNOWLEDGE is not supported through MDBs (or the inbound resource
@@ -76,5 +76,5 @@ the exception the message is individually acked.
 
 ## Example
 
-See the [examples](examples.md) chapter for an example which shows how to
-use pre-acknowledgement mode with JMS.
+See the [Pre-acknowledge Example](examples.md#pre-acknowledge) which shows how 
+to use pre-acknowledgement mode with JMS.

http://git-wip-us.apache.org/repos/asf/activemq-artemis/blob/40b66d13/docs/user-manual/en/preface.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/preface.md b/docs/user-manual/en/preface.md
index 6dccb7e..cbcc7d9 100644
--- a/docs/user-manual/en/preface.md
+++ b/docs/user-manual/en/preface.md
@@ -2,43 +2,43 @@
 
 What is Apache ActiveMQ Artemis?
 
--   Apache ActiveMQ Artemis is an open source project to build a multi-protocol,
-    embeddable, very high performance, clustered, asynchronous messaging
-    system.
+- Apache ActiveMQ Artemis is an open source project to build a multi-protocol,
+  embeddable, very high performance, clustered, asynchronous messaging
+  system.
 
--   Apache ActiveMQ Artemis is an example of Message Oriented Middleware (MoM). For a
-    description of MoMs and other messaging concepts please see the [Messaging Concepts](messaging-concepts.md).
+- Apache ActiveMQ Artemis is an example of Message Oriented Middleware (MoM). For a
+  description of MoMs and other messaging concepts please see the [Messaging Concepts](messaging-concepts.md).
 
 Why use Apache ActiveMQ Artemis? Here are just a few of the reasons:
 
--   100% open source software. Apache ActiveMQ Artemis is licensed using the Apache
-    Software License v 2.0 to minimise barriers to adoption.
+- 100% open source software. Apache ActiveMQ Artemis is licensed using the Apache
+  Software License v 2.0 to minimise barriers to adoption.
 
--   Apache ActiveMQ Artemis is designed with usability in mind.
+- Apache ActiveMQ Artemis is designed with usability in mind.
 
--   Written in Java. Runs on any platform with a Java 8+ runtime, that's
-    everything from Windows desktops to IBM mainframes.
+- Written in Java. Runs on any platform with a Java 8+ runtime, that's
+  everything from Windows desktops to IBM mainframes.
 
--   Amazing performance. Our ground-breaking high performance journal
-    provides persistent messaging performance at rates normally seen for
-    non-persistent messaging, our non-persistent messaging performance
-    rocks the boat too.
+- Amazing performance. Our ground-breaking high performance journal
+  provides persistent messaging performance at rates normally seen for
+  non-persistent messaging, our non-persistent messaging performance
+  rocks the boat too.
 
--   Full feature set. All the features you'd expect in any serious
-    messaging system, and others you won't find anywhere else.
+- Full feature set. All the features you'd expect in any serious
+  messaging system, and others you won't find anywhere else.
 
--   Elegant, clean-cut design with minimal third party dependencies. Run
-    ActiveMQ Artemis stand-alone, run it in integrated in your favourite Java EE
-    application server, or run it embedded inside your own product. It's
-    up to you.
+- Elegant, clean-cut design with minimal third party dependencies. Run
+  ActiveMQ Artemis stand-alone, run it in integrated in your favourite Java EE
+  application server, or run it embedded inside your own product. It's
+  up to you.
 
--   Seamless high availability. We provide a HA solution with automatic
-    client failover so you can guarantee zero message loss or
-    duplication in event of server failure.
+- Seamless high availability. We provide a HA solution with automatic
+  client failover so you can guarantee zero message loss or
+  duplication in event of server failure.
 
--   Hugely flexible clustering. Create clusters of servers that know how
-    to load balance messages. Link geographically distributed clusters
-    over unreliable connections to form a global network. Configure
-    routing of messages in a highly flexible way.
+- Hugely flexible clustering. Create clusters of servers that know how
+  to load balance messages. Link geographically distributed clusters
+  over unreliable connections to form a global network. Configure
+  routing of messages in a highly flexible way.
 
 

http://git-wip-us.apache.org/repos/asf/activemq-artemis/blob/40b66d13/docs/user-manual/en/project-info.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/project-info.md b/docs/user-manual/en/project-info.md
index 3dc4b72..a952c98 100644
--- a/docs/user-manual/en/project-info.md
+++ b/docs/user-manual/en/project-info.md
@@ -9,20 +9,19 @@ page:<http://activemq.apache.org/artemis/download.html>
 
 ## Project Information
 
--   If you have any user questions please use our [user
-    forum](http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html)
+- If you have any user questions please use our [user
+  forum](http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html)
 
--   If you have development related questions, please use our [developer
-    forum](http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html)
+- If you have development related questions, please use our [developer
+  forum](http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html)
 
--   Pop in and chat to us in our [IRC
-    channel](irc://irc.freenode.net:6667/apache-activemq)
+- Pop in and chat to us in our [IRC
+  channel](irc://irc.freenode.net:6667/apache-activemq)
 
--   Apache ActiveMQ Artemis Git repository is <https://github.com/apache/activemq-artemis>
-
--   All release tags are available from
-    <https://github.com/apache/activemq-artemis/releases>
+- Apache ActiveMQ Artemis Git repository is <https://github.com/apache/activemq-artemis>
 
+- All release tags are available from
+  <https://github.com/apache/activemq-artemis/releases>
 
 And many thanks to all our contributors, both old and new who helped
 create Apache ActiveMQ Artemis.


Mime
View raw message