activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From clebertsuco...@apache.org
Subject [16/16] activemq-artemis git commit: ARTEMIS-1912 big doc refactor
Date Thu, 07 Jun 2018 15:26:58 GMT
ARTEMIS-1912 big doc refactor

- Split protocols into individual chapters
- Reorganize summary to flow more logically
- Fill in missing parameters in configuration index
- Normalize spaces for ordered and unordered lists
- Re-wrap lots of text for readability
- Fix incorrect XML snippets
- Normalize table formatting
- Improve internal links with anchors
- Update content to reflect new address model
- Resized architecture images to avoid excessive white-space
- Update some JavaDoc
- Update some schema elements
- Disambiguate AIO & ASYNCIO where necessary
- Use URIs instead of Objects in code examples


Project: http://git-wip-us.apache.org/repos/asf/activemq-artemis/repo
Commit: http://git-wip-us.apache.org/repos/asf/activemq-artemis/commit/2b5d8f3b
Tree: http://git-wip-us.apache.org/repos/asf/activemq-artemis/tree/2b5d8f3b
Diff: http://git-wip-us.apache.org/repos/asf/activemq-artemis/diff/2b5d8f3b

Branch: refs/heads/master
Commit: 2b5d8f3b808a681d9306625c0005a1f454570407
Parents: 447829d
Author: Justin Bertram <jbertram@apache.org>
Authored: Fri Mar 9 09:07:38 2018 -0600
Committer: Clebert Suconic <clebertsuconic@apache.org>
Committed: Thu Jun 7 11:26:36 2018 -0400

----------------------------------------------------------------------
 .../artemis/api/core/client/ClientSession.java  |   40 +-
 .../resources/schema/artemis-configuration.xsd  |   52 +-
 docs/user-manual/en/SUMMARY.md                  |   17 +-
 docs/user-manual/en/address-model.md            |  891 ++++++-----
 docs/user-manual/en/amqp.md                     |  129 ++
 docs/user-manual/en/architecture.md             |  153 +-
 docs/user-manual/en/broker-plugins.md           |  242 +--
 docs/user-manual/en/client-classpath.md         |   17 +-
 docs/user-manual/en/client-reconnection.md      |  137 +-
 docs/user-manual/en/clusters.md                 |  842 +++++-----
 docs/user-manual/en/config-reload.md            |  199 ++-
 docs/user-manual/en/configuration-index.md      |  547 ++++---
 docs/user-manual/en/configuring-transports.md   |  707 ++++----
 docs/user-manual/en/connection-ttl.md           |   44 +-
 docs/user-manual/en/core-bridges.md             |  331 ++--
 docs/user-manual/en/core.md                     |  228 +++
 docs/user-manual/en/critical-analysis.md        |    8 +-
 docs/user-manual/en/data-tools.md               |  348 ++++
 docs/user-manual/en/diverts.md                  |    6 +-
 docs/user-manual/en/duplicate-detection.md      |    4 +-
 docs/user-manual/en/embedding-activemq.md       |   84 +-
 docs/user-manual/en/examples.md                 | 1026 ++++++------
 docs/user-manual/en/exclusive-queues.md         |   45 +-
 docs/user-manual/en/filter-expressions.md       |   42 +-
 docs/user-manual/en/flow-control.md             |   12 +-
 docs/user-manual/en/graceful-shutdown.md        |   30 +-
 docs/user-manual/en/ha.md                       |  334 ++--
 docs/user-manual/en/images/architecture1.jpg    |  Bin 62657 -> 76604 bytes
 docs/user-manual/en/images/architecture2.jpg    |  Bin 20043 -> 27525 bytes
 docs/user-manual/en/images/architecture3.jpg    |  Bin 14069 -> 15699 bytes
 docs/user-manual/en/intercepting-operations.md  |   85 +-
 docs/user-manual/en/jms-bridge.md               |  385 ++---
 docs/user-manual/en/jms-core-mapping.md         |   20 +-
 docs/user-manual/en/large-messages.md           |  214 ++-
 docs/user-manual/en/last-value-queues.md        |   37 +-
 docs/user-manual/en/libaio.md                   |   31 +-
 docs/user-manual/en/logging.md                  |  147 +-
 docs/user-manual/en/management-console.md       |   23 +-
 docs/user-manual/en/management.md               |  937 +++++------
 docs/user-manual/en/masking-passwords.md        |  267 ++--
 docs/user-manual/en/maven-plugin.md             |   50 +-
 docs/user-manual/en/message-expiry.md           |   66 +-
 docs/user-manual/en/message-grouping.md         |  247 ++-
 docs/user-manual/en/messaging-concepts.md       |  399 ++---
 docs/user-manual/en/mqtt.md                     |  137 ++
 docs/user-manual/en/network-isolation.md        |   90 +-
 docs/user-manual/en/openwire.md                 |  112 ++
 docs/user-manual/en/paging.md                   |  202 +--
 docs/user-manual/en/perf-tuning.md              |  517 +++---
 docs/user-manual/en/persistence.md              |  353 ++--
 docs/user-manual/en/pre-acknowledge.md          |   14 +-
 docs/user-manual/en/preface.md                  |   54 +-
 docs/user-manual/en/project-info.md             |   19 +-
 .../en/protocols-interoperability.md            |  663 +-------
 docs/user-manual/en/resource-limits.md          |    6 +-
 docs/user-manual/en/rest.md                     | 1293 ++++++++-------
 docs/user-manual/en/scheduled-messages.md       |    2 +-
 docs/user-manual/en/security.md                 | 1509 ++++++++++--------
 docs/user-manual/en/send-guarantees.md          |   18 +-
 docs/user-manual/en/slow-consumers.md           |    2 +-
 docs/user-manual/en/spring-integration.md       |   43 +-
 docs/user-manual/en/stomp.md                    |  293 ++++
 docs/user-manual/en/syntax.md                   |    2 +-
 docs/user-manual/en/tools.md                    |  216 ---
 docs/user-manual/en/undelivered-messages.md     |   30 +-
 docs/user-manual/en/unit-testing.md             |   42 +-
 docs/user-manual/en/upgrading.md                |   53 +-
 docs/user-manual/en/using-AMQP.md               |   74 -
 docs/user-manual/en/using-core.md               |  212 ---
 docs/user-manual/en/using-jms.md                |  414 ++---
 docs/user-manual/en/using-server.md             |  240 +--
 docs/user-manual/en/versions.md                 |    8 +-
 docs/user-manual/en/wildcard-routing.md         |    2 +-
 .../src/main/resources/broker.xml               |   13 +-
 .../src/main/resources/spring-jms-beans.xml     |    9 +-
 75 files changed, 8241 insertions(+), 7824 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/activemq-artemis/blob/2b5d8f3b/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/client/ClientSession.java
----------------------------------------------------------------------
diff --git a/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/client/ClientSession.java b/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/client/ClientSession.java
index ddc8168..dbc1e89 100644
--- a/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/client/ClientSession.java
+++ b/artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/client/ClientSession.java
@@ -427,7 +427,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em> queue.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @param durable   whether the queue is durable or not
     * @throws ActiveMQException in an exception occurs while creating the queue
@@ -440,7 +440,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Notice: you will get an exception if the address or the filter doesn't match to an already existent queue
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @param durable   if the queue is durable
     * @throws ActiveMQException in an exception occurs while creating the queue
@@ -453,7 +453,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Notice: you will get an exception if the address or the filter doesn't match to an already existent queue
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @param filter    whether the queue is durable or not
     * @param durable   if the queue is durable
@@ -466,7 +466,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates Shared queue. A queue that will exist as long as there are consumers or is durable.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @param filter    whether the queue is durable or not
     * @param durable   if the queue is durable
@@ -483,7 +483,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em> queue.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @param durable   whether the queue is durable or not
     * @throws ActiveMQException in an exception occurs while creating the queue
@@ -494,7 +494,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em> queue <em>non-durable</em> queue.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @throws ActiveMQException in an exception occurs while creating the queue
     */
@@ -504,7 +504,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em> queue <em>non-durable</em> queue.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @throws ActiveMQException in an exception occurs while creating the queue
     */
@@ -514,7 +514,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em> queue.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @param filter    only messages which match this filter will be put in the queue
     * @param durable   whether the queue is durable or not
@@ -527,7 +527,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em>queue.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @param filter    only messages which match this filter will be put in the queue
     * @param durable   whether the queue is durable or not
@@ -539,7 +539,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em> queue.
     *
     * @param address     the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName   the name of the queue
     * @param filter      only messages which match this filter will be put in the queue
     * @param durable     whether the queue is durable or not
@@ -553,7 +553,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em> queue.
     *
     * @param address      the queue will be bound to this address
-    * @param routingType  the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType  the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName    the name of the queue
     * @param filter       only messages which match this filter will be put in the queue
     * @param durable      whether the queue is durable or not
@@ -569,7 +569,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em> queue.
     *
     * @param address      the queue will be bound to this address
-    * @param routingType  the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType  the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName    the name of the queue
     * @param filter       only messages which match this filter will be put in the queue
     * @param durable      whether the queue is durable or not
@@ -587,7 +587,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em>queue.
     *
     * @param address     the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName   the name of the queue
     * @param filter      only messages which match this filter will be put in the queue
     * @param durable     whether the queue is durable or not
@@ -600,7 +600,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em>queue.
     *
     * @param address     the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName   the name of the queue
     * @param filter      only messages which match this filter will be put in the queue
     * @param durable     whether the queue is durable or not
@@ -616,7 +616,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>non-temporary</em>queue.
     *
     * @param address     the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName   the name of the queue
     * @param filter      only messages which match this filter will be put in the queue
     * @param durable     whether the queue is durable or not
@@ -634,7 +634,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>temporary</em> queue.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @throws ActiveMQException in an exception occurs while creating the queue
     */
@@ -644,7 +644,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>temporary</em> queue.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @throws ActiveMQException in an exception occurs while creating the queue
     */
@@ -654,7 +654,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>temporary</em> queue with a filter.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @param filter    only messages which match this filter will be put in the queue
     * @param maxConsumers how many concurrent consumers will be allowed on this queue
@@ -670,7 +670,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>temporary</em> queue with a filter.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @param filter    only messages which match this filter will be put in the queue
     * @throws ActiveMQException in an exception occurs while creating the queue
@@ -681,7 +681,7 @@ public interface ClientSession extends XAResource, AutoCloseable {
     * Creates a <em>temporary</em> queue with a filter.
     *
     * @param address   the queue will be bound to this address
-    * @param routingType the delivery mode for this queue, MULTICAST or ANYCAST
+    * @param routingType the routing type for this queue, MULTICAST or ANYCAST
     * @param queueName the name of the queue
     * @param filter    only messages which match this filter will be put in the queue
     * @throws ActiveMQException in an exception occurs while creating the queue

http://git-wip-us.apache.org/repos/asf/activemq-artemis/blob/2b5d8f3b/artemis-server/src/main/resources/schema/artemis-configuration.xsd
----------------------------------------------------------------------
diff --git a/artemis-server/src/main/resources/schema/artemis-configuration.xsd b/artemis-server/src/main/resources/schema/artemis-configuration.xsd
index 6a70671..831b4cb 100644
--- a/artemis-server/src/main/resources/schema/artemis-configuration.xsd
+++ b/artemis-server/src/main/resources/schema/artemis-configuration.xsd
@@ -69,9 +69,8 @@
             <xsd:annotation>
                <xsd:documentation>
                   If true then the ActiveMQ Artemis Server will make use of any Protocol Managers that are in available
-                  on the
-                  classpath. If false then only the core protocol will be available, unless in Embedded mode where users
-                  can inject their own Protocol Managers.
+                  on the classpath. If false then only the core protocol will be available, unless in Embedded mode
+                  where users can inject their own Protocol Managers.
                </xsd:documentation>
             </xsd:annotation>
          </xsd:element>
@@ -216,7 +215,7 @@
          <xsd:element name="log-delegate-factory-class-name" type="xsd:string" maxOccurs="1" minOccurs="0">
             <xsd:annotation>
                <xsd:documentation>
-                  XXX
+                  DEPRECATED: the name of the factory class to use for log delegation
                </xsd:documentation>
             </xsd:annotation>
          </xsd:element>
@@ -356,7 +355,7 @@
          <xsd:element name="remoting-incoming-interceptors" type="class-name-sequenceType" maxOccurs="1" minOccurs="0">
             <xsd:annotation>
                <xsd:documentation>
-                  a list of &lt;class-name/&gt; elements with the names of classes to use for interceptor incoming
+                  a list of &lt;class-name/&gt; elements with the names of classes to use for intercepting incoming
                   remoting packets
                </xsd:documentation>
             </xsd:annotation>
@@ -365,7 +364,7 @@
          <xsd:element name="remoting-outgoing-interceptors" type="class-name-sequenceType" maxOccurs="1" minOccurs="0">
             <xsd:annotation>
                <xsd:documentation>
-                  a list of &lt;class-name/&gt; elements with the names of classes to use for interceptor outcoming
+                  a list of &lt;class-name/&gt; elements with the names of classes to use for intercepting outgoing
                   remoting packets
                </xsd:documentation>
             </xsd:annotation>
@@ -713,10 +712,10 @@
             </xsd:annotation>
          </xsd:element>
 
-         <xsd:element name="journal-file-open-timeout" type="xsd:int" maxOccurs="1" minOccurs="0">
+         <xsd:element name="journal-file-open-timeout" type="xsd:int" default="5" maxOccurs="1" minOccurs="0">
             <xsd:annotation>
                <xsd:documentation>
-                  the length of time to wait when opening a new Journal file before timing out and failing
+                  the length of time in seconds to wait when opening a new Journal file before timing out and failing
                </xsd:documentation>
             </xsd:annotation>
          </xsd:element>
@@ -867,7 +866,7 @@
                            <xsd:attribute name="match" type="xsd:string" use="required">
                               <xsd:annotation>
                                  <xsd:documentation>
-                                    regular expression for matching security roles against addresses
+                                    pattern for matching security roles against addresses; can use wildards
                                  </xsd:documentation>
                               </xsd:annotation>
                            </xsd:attribute>
@@ -1075,7 +1074,7 @@
          <xsd:element name="wildcard-addresses" type="wildcardType" maxOccurs="1" minOccurs="0">
             <xsd:annotation>
                <xsd:documentation>
-                  Wildcard addresses format
+                  parameters to configure wildcard address matching format
                </xsd:documentation>
             </xsd:annotation>
          </xsd:element>
@@ -1103,9 +1102,20 @@
    <xsd:element name="broadcast-group">
       <xsd:complexType>
          <xsd:sequence>
-            <!-- XXX these 2 local-* here...-->
-            <xsd:element ref="local-bind-address" maxOccurs="1" minOccurs="0"/>
-            <xsd:element ref="local-bind-port" maxOccurs="1" minOccurs="0"/>
+            <xsd:element ref="local-bind-address" maxOccurs="1" minOccurs="0">
+               <xsd:annotation>
+                  <xsd:documentation>
+                     a local address to which the datagram socket is bound
+                  </xsd:documentation>
+               </xsd:annotation>
+            </xsd:element>
+            <xsd:element ref="local-bind-port" maxOccurs="1" minOccurs="0">
+               <xsd:annotation>
+                  <xsd:documentation>
+                     a local port to which the datagram socket is bound
+                  </xsd:documentation>
+               </xsd:annotation>
+            </xsd:element>
             <xsd:element name="group-address" type="xsd:string" maxOccurs="1" minOccurs="0">
                <xsd:annotation>
                   <xsd:documentation>
@@ -1163,7 +1173,6 @@
    <xsd:element name="discovery-group">
       <xsd:complexType>
          <xsd:all>
-            <!-- XXX -->
             <xsd:element name="group-address" type="xsd:string" maxOccurs="1" minOccurs="0">
                <xsd:annotation>
                   <xsd:documentation>
@@ -1650,8 +1659,7 @@
             <xsd:annotation>
                <xsd:documentation>
                   DEPRECATED: use message-load-balancing-type instead. Select STRICT to mimic
-                  forward-when-no-consumers=true
-                  and ON_DEMAND to mimic forward-when-no-consumers=false.
+                  forward-when-no-consumers=true and ON_DEMAND to mimic forward-when-no-consumers=false.
                </xsd:documentation>
             </xsd:annotation>
          </xsd:element>
@@ -1750,7 +1758,7 @@
                   <xsd:attribute name="discovery-group-name" type="xsd:IDREF" use="required">
                      <xsd:annotation>
                         <xsd:documentation>
-                           XXX -- this is a duplicate...
+                           name of discovery group used by this cluster-connection
                         </xsd:documentation>
                      </xsd:annotation>
                   </xsd:attribute>
@@ -2961,7 +2969,7 @@
                </xsd:annotation>
             </xsd:element>
 
-            <xsd:element name="default-max-consumers" type="xsd:int" default="200" maxOccurs="1" minOccurs="0">
+            <xsd:element name="default-max-consumers" type="xsd:int" default="-1" maxOccurs="1" minOccurs="0">
                <xsd:annotation>
                   <xsd:documentation>
                      the maximum number of consumers allowed on this queue at any one time
@@ -2990,7 +2998,7 @@
          <xsd:attribute name="match" type="xsd:string" use="required">
             <xsd:annotation>
                <xsd:documentation>
-                  XXX
+                  pattern for matching settings against addresses; can use wildards
                </xsd:documentation>
             </xsd:annotation>
          </xsd:attribute>
@@ -3009,7 +3017,7 @@
             <xsd:element name="max-connections" type="xsd:int" default="-1" maxOccurs="1" minOccurs="0">
                <xsd:annotation>
                   <xsd:documentation>
-                     how many connections are allowed by the matched entity (-1 means no limit, default is -1)
+                     how many connections are allowed by the matched user (-1 means no limit, default is -1)
                   </xsd:documentation>
                </xsd:annotation>
             </xsd:element>
@@ -3017,7 +3025,7 @@
             <xsd:element name="max-queues" type="xsd:int" default="-1" maxOccurs="1" minOccurs="0">
                <xsd:annotation>
                   <xsd:documentation>
-                     how many queues can be created by the matched entity (-1 means no limit, default is -1)
+                     how many queues can be created by the matched user (-1 means no limit, default is -1)
                   </xsd:documentation>
                </xsd:annotation>
             </xsd:element>
@@ -3146,7 +3154,7 @@
       <xsd:attribute name="name" type="xsd:string" use="required">
          <xsd:annotation>
             <xsd:documentation>
-               The address name to matches incoming message addresses
+               The address name to match incoming message addresses
             </xsd:documentation>
          </xsd:annotation>
       </xsd:attribute>

http://git-wip-us.apache.org/repos/asf/activemq-artemis/blob/2b5d8f3b/docs/user-manual/en/SUMMARY.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/SUMMARY.md b/docs/user-manual/en/SUMMARY.md
index c93f759..86273cc 100644
--- a/docs/user-manual/en/SUMMARY.md
+++ b/docs/user-manual/en/SUMMARY.md
@@ -10,14 +10,18 @@
 * [Using the Server](using-server.md)
 * [Upgrading](upgrading.md)
 * [Address Model](address-model.md)
-* [Using JMS](using-jms.md)
-* [Using Core](using-core.md)
-* [Using AMQP](using-AMQP.md)
+* [Protocols and Interoperability](protocols-interoperability.md)
+* [AMQP](amqp.md)
+* [MQTT](mqtt.md)
+* [STOMP](stomp.md)
+* [OpenWire](openwire.md)
+* [Core](core.md)
 * [Mapping JMS Concepts to the Core API](jms-core-mapping.md)
+* [Using JMS](using-jms.md)
 * [The Client Classpath](client-classpath.md)
 * [Examples](examples.md)
 * [Routing Messages With Wild Cards](wildcard-routing.md)
-* [Understanding the Apache ActiveMQ Artemis Wildcard Syntax](wildcard-syntax.md)
+* [Wildcard Syntax](wildcard-syntax.md)
 * [Filter Expressions](filter-expressions.md)
 * [Persistence](persistence.md)
 * [Configuring Transports](configuring-transports.md)
@@ -56,14 +60,13 @@
 * [Thread management](thread-pooling.md)
 * [Logging](logging.md)
 * [REST Interface](rest.md)
-* [Embedding Apache ActiveMQ Artemis](embedding-activemq.md)
+* [Embedding the Broker](embedding-activemq.md)
 * [Apache Karaf](karaf.md)
 * [Apache Tomcat](tomcat.md)
 * [Spring Integration](spring-integration.md)
 * [CDI Integration](cdi-integration.md)
 * [Intercepting Operations](intercepting-operations.md)
-* [Protocols and Interoperability](protocols-interoperability.md)
-* [Tools](tools.md)
+* [Data Tools](data-tools.md)
 * [Maven Plugin](maven-plugin.md)
 * [Unit Testing](unit-testing.md)
 * [Troubleshooting and Performance Tuning](perf-tuning.md)

http://git-wip-us.apache.org/repos/asf/activemq-artemis/blob/2b5d8f3b/docs/user-manual/en/address-model.md
----------------------------------------------------------------------
diff --git a/docs/user-manual/en/address-model.md b/docs/user-manual/en/address-model.md
index 1673e21..f73adf2 100644
--- a/docs/user-manual/en/address-model.md
+++ b/docs/user-manual/en/address-model.md
@@ -1,33 +1,66 @@
 # Addressing Model
 
-Apache ActiveMQ Artemis has a unique addressing model that is both powerful and flexible and that offers great performance. The addressing model comprises three main concepts: addresses, queues and routing types.
+Apache ActiveMQ Artemis has a unique addressing model that is both powerful and
+flexible and that offers great performance. The addressing model comprises
+three main concepts: **addresses**, **queues** and **routing types**.
 
-An address represents a messaging endpoint. Within the configuration, a typical address is given a unique name, 0 or more queues, and a routing type.
+### Address
 
-A queue is associated with an address. There can be multiple queues per address. Once an incoming message is matched to an address, the message will be sent on to one or more of its queues, depending on the routing type configured. Queues can be configured to be automatically created and deleted.
+An address represents a messaging endpoint. Within the configuration, a typical
+address is given a unique name, 0 or more queues, and a routing type.
 
-A routing type determines how messages are sent to the queues associated with an address. An Apache ActiveMQ Artemis address can be configured with two different routing types.
+### Queue
+
+A queue is associated with an address. There can be multiple queues per
+address. Once an incoming message is matched to an address, the message will be
+sent on to one or more of its queues, depending on the routing type configured.
+Queues can be configured to be automatically created and deleted.
+
+### Routing Types
+
+A routing type determines how messages are sent to the queues associated with
+an address. An Apache ActiveMQ Artemis address can be configured with two
+different routing types.
 
 Table 1. Routing Types
 
-| If you want your messages routed to…​	                                   | Use this routing type …​ |
-| :----------------------------------------------------------------------: | :---------------------: |
-| A single queue within the matching address, in a point-to-point manner.  | Anycast                 |
-| Every queue within the matching address, in a publish-subscribe manner.  | Multicast               |
+If you want your messages routed to...|Use this routing type...
+---|---
+A single queue within the matching address, in a point-to-point manner.|Anycast
+Every queue within the matching address, in a publish-subscribe manner.|Multicast
+
 
---------------------------------------------------------------------------------------------
-**Note:** It is possible to define more than one routing type per address, but this typically results in an anti-pattern and is therefore not recommended.  If an address does use both routing types, however, and the client does not show a preference for either one, the broker typically defaults to the anycast routing type.
-The one exception is when the client uses the MQTT protocol. In that case, the default routing type is multicast. |
+**Note:** It is possible to define more than one routing type per address, but
+this typically results in an anti-pattern and is therefore not recommended.  If
+an address does use both routing types, however, and the client does not show a
+preference for either one, the broker typically defaults to the anycast routing
+type.
+
+The one exception is when the client uses the MQTT protocol. In that case, the
+default routing type is multicast.
+
+For additional details about these concepts refer to [the core](core.md) chapter.
 
 ## Basic Address Configuration
 
-The following examples show how to configure basic point to point and publish subscribe addresses.
+The following examples show how to configure basic point to point and publish
+subscribe addresses.
 
 ### Point-to-Point Messaging
 
-Point-to-point messaging is a common scenario in which a message sent by a producer has only one consumer. AMQP and JMS message producers and consumers can make use of point-to-point messaging queues, for example. Define an anycast routing type for an address so that its queues receive messages in a point-to-point manner.
+Point-to-point messaging is a common scenario in which a message sent by a
+producer has only one consumer. AMQP and JMS message producers and consumers
+can make use of point-to-point messaging queues, for example. Define an anycast
+routing type for an address so that its queues receive messages in a
+point-to-point manner.
 
-When a message is received on an address using anycast, Apache ActiveMQ Artemis locates the queue associated with the address and routes the message to it. When consumers request to consume from the address, the broker locates the relevant queue and associates this queue with the appropriate consumers. If multiple consumers are connected to the same queue, messages are distributed amongst each consumer equally, providing the consumers are equally able to handle them.
+When a message is received on an address using anycast, Apache ActiveMQ Artemis
+locates the queue associated with the address and routes the message to it.
+When consumers request to consume from the address, the broker locates the
+relevant queue and associates this queue with the appropriate consumers. If
+multiple consumers are connected to the same queue, messages are distributed
+amongst each consumer equally, providing the consumers are equally able to
+handle them.
 
 ![Point to Point](images/addressing-model-p2p.png)
 Figure 1. Point to Point Messaging
@@ -36,180 +69,207 @@ Figure 1. Point to Point Messaging
 
 Open the file `<broker-instance>/etc/broker.xml` for editing.
 
-Add an address configuration element and its associated queue if they do not exist already.
+Add an address configuration element and its associated queue if they do not
+exist already.
 
-**Note** For normal Point to Point semantics, the queue name **MUST** match the address name.
+**Note:** For normal Point to Point semantics, the queue name **MUST** match the
+address name.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <address name="orders">
+<addresses>
+   <address name="orders">
       <anycast>
-        <queue name="orders"/>
+         <queue name="orders"/>
       </anycast>
-    </address>
-  </core>
-</configuration>
+   </address>
+</addresses>
 ```
 
 ### Publish-Subscribe Messaging
 
-In a publish-subscribe scenario, messages are sent to every consumer subscribed to an address. JMS topics and MQTT subscriptions are two examples of publish-subscribe messaging.
+In a publish-subscribe scenario, messages are sent to every consumer subscribed
+to an address. JMS topics and MQTT subscriptions are two examples of
+publish-subscribe messaging.
 
-To configure an address with publish-subscribe semantics, create an address with the multicast routing type.
+To configure an address with publish-subscribe semantics, create an address
+with the multicast routing type.
 
 ![Publish Subscribe](images/addressing-model-pubsub.png)
 Figure 2. Publish-Subscribe
 
 #### Using the Multicast Routing Type
 
-Open the file <broker-instance>/etc/broker.xml for editing.
+Open the file `<broker-instance>/etc/broker.xml` for editing.
 
 Add an address configuration element with multicast routing type.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <address name="pubsub.foo">
+<addresses>
+   <address name="pubsub.foo">
       <multicast/>
-    </address>
-  </core>
-</configuration>
+   </address>
+</addresses>
 ```
 
-When clients connect to an address with the multicast element, a subscription queue for the client will be automatically created for the client. It is also possible to pre-configure subscription queues and connect to them directly using the queue's [Fully Qualified Queue names](#fully-qualified-queue-names).
+When clients connect to an address with the multicast element, a subscription
+queue for the client will be automatically created for the client. It is also
+possible to pre-configure subscription queues and connect to them directly
+using the queue's [Fully Qualified Queue names](#fully-qualified-queue-names).
 
-Optionally add one or more queue elements to the address and wrap the multicast element around them. This step is typically not needed since the broker will automatically create a queue for each subscription requested by a client.
+Optionally add one or more queue elements to the address and wrap the multicast
+element around them. This step is typically not needed since the broker will
+automatically create a queue for each subscription requested by a client.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <address name="pubsub.foo">
+<addresses>
+   <address name="pubsub.foo">
       <multicast>
-        <queue name="client123.pubsub.foo"/>
-        <queue name="client456.pubsub.foo"/>
+         <queue name="client123.pubsub.foo"/>
+         <queue name="client456.pubsub.foo"/>
       </multicast>
-    </address>
-  </core>
-</configration>
+   </address>
+</addresses>
 ```
 
 Figure 3. Point-to-Point with Two Queues
 
 ### Point-to-Point Address multiple Queues
 
-It is actually possible to define more than one queue on an address with an anycast routing type. When messages are received on such an address, they are firstly distributed evenly across all the defined queues. Using [Fully Qualified Queue names](#fully-qualified-queue-names), clients are able to select the queue that they would like to subscribe to. Should more than one consumer connect direct to a single queue, Apache ActiveMQ Artemis will take care of distributing messages between them, as in the example above.
+It is actually possible to define more than one queue on an address with an
+anycast routing type. When messages are received on such an address, they are
+firstly distributed evenly across all the defined queues. Using [Fully
+Qualified Queue names](#fully-qualified-queue-names), clients are able to
+select the queue that they would like to subscribe to. Should more than one
+consumer connect direct to a single queue, Apache ActiveMQ Artemis will take
+care of distributing messages between them, as in the example above.
 
 ![Point to Point](images/addressing-model-p2p2.png)
 Figure 3. Point-to-Point with Two Queues
 
---------------------------------------------------------------------------------------------
-**Note:** This is how Apache ActiveMQ Artemis handles load balancing of queues across multiple nodes in a cluster.
-Configuring a Point-to-Point Address with two queues, open the file <broker-instance>/etc/broker.xml for editing.
+**Note:** This is how Apache ActiveMQ Artemis handles load balancing of queues
+across multiple nodes in a cluster.  Configuring a Point-to-Point Address with
+two queues, open the file `<broker-instance>/etc/broker.xml` for editing.
 
-Add an address configuration with Anycast routing type element and its associated queues.
+Add an address configuration with Anycast routing type element and its
+associated queues.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <address name="address.foo">
+<addresses>
+   <address name="address.foo">
       <anycast>
-        <queue name="q1"/>
-        <queue name="q2"/>
+         <queue name="q1"/>
+         <queue name="q2"/>
       </anycast>
-    </address>
-  </core>
-</configuration>
+   </address>
+</addresses>
 ```
 
 ### Point-to-Point and Publish-Subscribe Addresses
 
-It is possible to define an address with both point-to-point and publish-subscribe semantics enabled. While not typically recommend, this can be useful when you want, for example, a JMS Queue say orders and a JMS Topic named orders. The different routing types make the addresses appear to be distinct.
+It is possible to define an address with both point-to-point and
+publish-subscribe semantics enabled. While not typically recommend, this can be
+useful when you want, for example, a JMS Queue say orders and a JMS Topic named
+orders.  The different routing types make the addresses appear to be distinct.
 
-Using an example of JMS Clients, the messages sent by a JMS message producer will be routed using the anycast routing type. Messages sent by a JMS topic producer will use the multicast routing type. In addition when a JMS topic consumer attaches, it will be attached to it’s own subscription queue. JMS queue consumer will be attached to the anycast queue.
+Using an example of JMS Clients, the messages sent by a JMS message producer
+will be routed using the anycast routing type. Messages sent by a JMS topic
+producer will use the multicast routing type. In addition when a JMS topic
+consumer attaches, it will be attached to it’s own subscription queue. JMS
+queue consumer will be attached to the anycast queue.
 
 ![Point to Point](images/addressing-model-p2p-pubsub.png)
-Figure 4. [Point-to-Point and Publish-Subscribe
-
---------------------------------------------------------------------------------------------
-**Note:** The behavior in this scenario is dependent on the protocol being used. For JMS there is a clear distinction between topic and queue producers and consumers, which make the logic straight forward. Other protocols like AMQP do not make this distinction. A message being sent via AMQP will be routed by both anycast and multicast and consumers will default to anycast. For more information, please check the behavior of each protocol in the sections on protocols.
-
-The XML snippet below is an example of what the configuration for an address using both anycast and multicast would look like in <broker-instance>/etc/broker.xml. Note that subscription queues are typically created on demand, so there is no need to list specific queue elements inside the multicast routing type.
+Figure 4. Point-to-Point and Publish-Subscribe
+
+**Note:** The behavior in this scenario is dependent on the protocol being
+used. For JMS there is a clear distinction between topic and queue producers
+and consumers, which make the logic straight forward. Other protocols like AMQP
+do not make this distinction. A message being sent via AMQP will be routed by
+both anycast and multicast and consumers will default to anycast. For more
+information, please check the behavior of each protocol in the sections on
+protocols.
+
+The XML snippet below is an example of what the configuration for an address
+using both anycast and multicast would look like in
+`<broker-instance>/etc/broker.xml`. Note that subscription queues are typically
+created on demand, so there is no need to list specific queue elements inside
+the multicast routing type.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <address name="foo.orders">
+<addresses>
+   <address name="foo.orders">
       <anycast>
-        <queue name="orders"/>
+         <queue name="orders"/>
       </anycast>
       <multicast/>
-    </address>
-  </core>
-</configuration>
+   </address>
+</addresses>
 ```
 
 ## How to filter messages
 
-Apache ActiveMQ Artemis supports the ability to filter messages using Apache Artemis [Filter Expressions](filter-expressions.md).
+Apache ActiveMQ Artemis supports the ability to filter messages using Apache
+Artemis [Filter Expressions](filter-expressions.md).
 
 Filters can be applied in two places, on a queue and on a consumer.
 
 ### Queue Filter
 
-When a filter is applied to a queue, messages are filter before they sent to the queue.  To add a queue filter use the
-filter element when configuring a queue.  Open up the broker.xml and add an address with a queue, using the filter element
-to configure a filter on this queue.
+When a filter is applied to a queue, messages are filter before they sent to
+the queue.  To add a queue filter use the filter element when configuring a
+queue.  Open up `<broker-instance>/etc/broker.xml` and add an address with a
+queue, using the filter element to configure a filter on this queue.
 
 ```xml
-<address name="filter">
-   <queue name="filter">
-      <filter string="color='red'"/>
-    </queue>
-</address>
+<addresses>
+   <address name="filter">
+      <queue name="filter">
+         <filter string="color='red'"/>
+      </queue>
+   </address>
+</addresses>
 ```
 
-The filter defined above ensures that only messages with an attribute "color='red'" is sent to this queue.
+The filter defined above ensures that only messages with an attribute
+`"color='red'"` is sent to this queue.
 
 ### Consumer Filters
 
-Consumer filters are applied after messages have reached a queue and are defined using the appropriate client APIs.  The
-follow JMS example shows how to consumer filters work.
+Consumer filters are applied after messages have reached a queue and are
+defined using the appropriate client APIs.  The follow JMS example shows how to
+consumer filters work.
 
 1. Define an address with a single queue, with no filter applied.
 
 ```xml
-<address name="filter">
-   <queue name="filter"/>
-</address>
+<addresses>
+   <address name="filter">
+      <queue name="filter"/>
+   </address>
+</addresses>
 ```
 
 ```java
-  ...
-  // Send some messages
-  for (int i = 0; i < 3; i ++) {
-    TextMessage redMessage = senderSession.createTextMessage("Red");
-    redMessage.setStringProperty("color", "red");
-    producer.send(redMessage)
-        
-    TextMessage greenMessage = senderSession.createTextMessage("Green");
-    greenMessage.setStringProperty("color", "green");
-    producer.send(greenMessage)
-  }
+...
+// Send some messages
+for (int i = 0; i < 3; i ++) {
+  TextMessage redMessage = senderSession.createTextMessage("Red");
+  redMessage.setStringProperty("color", "red");
+  producer.send(redMessage)
+
+  TextMessage greenMessage = senderSession.createTextMessage("Green");
+  greenMessage.setStringProperty("color", "green");
+  producer.send(greenMessage)
+}
 ```
 
 At this point the queue would have 6 messages: red,green,red,green,red,green
          
 ```java
-  MessageConsumer redConsumer = redSession.createConsumer(queue, "color='red'");
+MessageConsumer redConsumer = redSession.createConsumer(queue, "color='red'");
 ```
 
-The redConsumer has a filter that only matches "red" messages.  The redConsumer will receive 3 messages.
+The redConsumer has a filter that only matches "red" messages.  The redConsumer
+will receive 3 messages.
 
 ```
 red, red, red
@@ -223,92 +283,100 @@ green, green, green
 
 ## Automatic Address/Queue Management
 
-You can configure Apache ActiveMQ Artemis to automatically create addresses and queues, and then delete them when they are no longer in use. This saves you from having to preconfigure each address and queue before a client can connect to it. Automatic creation and deletion is configured on a per address basis and is controlled by following:
+You can configure Apache ActiveMQ Artemis to automatically create addresses and
+queues, and then delete them when they are no longer in use. This saves you
+from having to preconfigure each address and queue before a client can connect
+to it. Automatic creation and deletion is configured on a per address basis and
+is controlled by following:
 
-| Parameter | Description |
-|-----------|-------------|
-| auto-create-addresses | When set to true, the broker will create the address requested by the client if it does not exist already. The default is true.|
-| auto-delete-addresses | When set to true, the broker will be delete any **auto-created** adddress once all of it’s queues have been deleted. The default is true |
-|default-address-routing-type | The routing type to use if the client does not specify one.   Possible values are MULTICAST and ANYCAST. See earlier in this chapter for more information about routing types. The default value is MULTICAST. |
+Parameter|Description
+---|---
+`auto-create-addresses`|When set to true, the broker will create the address requested by the client if it does not exist already. The default is `true`.
+`auto-delete-addresses`|When set to true, the broker will be delete any **auto-created** adddress once all of it’s queues have been deleted. The default is `true`
+`default-address-routing-type`|The routing type to use if the client does not specify one. Possible values are `MULTICAST` and `ANYCAST`. See earlier in this chapter for more information about routing types. The default value is `MULTICAST`.
 
 ### Auto Address Creation
 
-- Edit the file `<broker-instance>/etc/broker.xml` and add the `auto-create-addresses` element to the `address-setting` you want the broker to automatically create.
+- Edit the file `<broker-instance>/etc/broker.xml` and add the
+  `auto-create-addresses` element to the `address-setting` you want the broker
+  to automatically create.
 
-- (Optional) Add the `address-setting` if it does not exits. Use the match parameter and the [wildcard syntax](wildcard-syntax.md) to match more than one specific address.
+- (Optional) Add the `address-setting` if it does not exits. Use the match
+  parameter and the [wildcard syntax](wildcard-syntax.md) to match more than
+  one specific address.
 
 - Set `auto-create-addresses` to `true`
 
-- (Optional) Assign `MULTICAST` or `ANYCAST` as the default routing type for the address.
+- (Optional) Assign `MULTICAST` or `ANYCAST` as the default routing type for
+  the address.
 
-The example below configures an `address-setting` to be automatically created by the broker. The default routing type to be used if not specified by the client is MULTICAST. Note that wildcard syntax is used. Any address starting with /news/politics/ will be automatically created by the broker.
+The example below configures an `address-setting` to be automatically created
+by the broker. The default routing type to be used if not specified by the
+client is MULTICAST. Note that wildcard syntax is used. Any address starting
+with `/news/politics/` will be automatically created by the broker.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <address-settings>
-       <address-setting match="/news/politics/#">
-          <auto-create-addresses>true</auto-create-addresses>
-          <default-address-routing-type>MULTICAST</default-address-routing-type>
-       </address-setting>
-    </address-settings>
-    ...
-  </core>
-</configuration>
+<address-setting match="/news/politics/#">
+  <auto-create-addresses>true</auto-create-addresses>
+  <default-address-routing-type>MULTICAST</default-address-routing-type>
+</address-setting>
 ```
 
 ### Auto Address Deletion
 
-Edit the file `<broker-instance>/etc/broker.xml` and add the `auto-delete-addresses` element to the `address-setting` you want the broker to automatically create.
+- Edit the file `<broker-instance>/etc/broker.xml` and add the
+  `auto-delete-addresses` element to the `address-setting` you want the broker to
+  automatically create.
 
-(Optional) Add the `address-setting` if it does not exits. Use the match parameter and the [wildcard syntax](wildcard-syntax.md) to match more than one specific address.
+- (Optional) Add the `address-setting` if it does not exits. Use the match
+  parameter and the [wildcard syntax](wildcard-syntax.md) to match more than one
+  specific address.
 
-Set `auto-delete-addresses` to `true`
+- Set `auto-delete-addresses` to `true`
 
-The example below configures an `address-setting` to be automatically deleted by the broker. Note that wildcard syntax is used. Any address request by the client that starts with `/news/politics/` is configured to be automatically deleted by the broker.
+The example below configures an `address-setting` to be automatically deleted
+by the broker. Note that wildcard syntax is used. Any address request by the
+client that starts with `/news/politics/` is configured to be automatically
+deleted by the broker.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <address-settings>
-       <address-setting match="/news/politics/#">
-          <auto-delete-addresses>true</auto-delete-addresses>
-          <default-address-routing-type>MULTICAST</default-address-routing-type>
-       </address-setting>
-    </address-settings>
-    ...
-  </core>
-</configuration>
+<address-setting match="/news/politics/#">
+  <auto-delete-addresses>true</auto-delete-addresses>
+  <default-address-routing-type>MULTICAST</default-address-routing-type>
+</address-setting>
 ```
 
 ## "Fully Qualified" Queue Names
 
-Internally the broker maps a client’s request for an address to specific queues. The broker decides on behalf of the client which queues to send messages to or from which queue to receive messages. However, more advanced use cases might require that the client specify a queue directly. In these situations the client and use a fully qualified queue name, by specifying both the address name and the queue name, separated by a ::.
+Internally the broker maps a client’s request for an address to specific
+queues. The broker decides on behalf of the client which queues to send
+messages to or from which queue to receive messages. However, more advanced use
+cases might require that the client specify a queue directly. In these
+situations the client and use a fully qualified queue name, by specifying both
+the address name and the queue name, separated by a ::.
 
-Currently Artemis supports fully qualified queue names on Core, AMQP, JMS, OpenWire, MQTT and Stomp protocols for receiving messages only.
+Currently Artemis supports fully qualified queue names on Core, AMQP, JMS,
+OpenWire, MQTT and Stomp protocols for receiving messages only.
 
 ### Specifying a Fully Qualified Queue Name
-In this example, the address foo is configured with two queues q1, q2 as shown in the configuration below.
+
+In this example, the address foo is configured with two queues q1, q2 as shown
+in the configuration below.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <addresses>
-       <address name="foo">
-          <anycast>
-             <queue name="q1" />
-             <queue name="q2" />
-          </anycast>
-       </address>
-    </addresses>
-  </core>
-</configuration>
+<addresses>
+   <address name="foo">
+      <anycast>
+         <queue name="q1" />
+         <queue name="q2" />
+      </anycast>
+   </address>
+</addresses>
 ```
 
-In the client code, use both the address name and the queue name when requesting a connection from the broker. Remember to use two colons, ::, to separate the names, as in the example Java code below.
+In the client code, use both the address name and the queue name when
+requesting a connection from the broker. Remember to use two colons, `::`, to
+separate the names, as in the example Java code below.
 
 ```java
 String FQQN = "foo::q1";
@@ -318,302 +386,407 @@ MessageConsumer consumer = session.createConsumer(q1);
 
 ## Using Prefixes to Determine Routing Type
 
-Normally, if the broker receives a message sent to a particular address, that has both `ANYCAST` and `MULTICAST` routing types enable, it will route a copy of the message to **one** of the `ANYCAST` queues and to **all** of the `MULTICAST` queues.
+Normally, if the broker receives a message sent to a particular address, that
+has both `ANYCAST` and `MULTICAST` routing types enable, it will route a copy
+of the message to **one** of the `ANYCAST` queues and to **all** of the
+`MULTICAST` queues.
 
-However, clients can specify a special prefix when connecting to an address to indicate which kind of routing type to use. The prefixes are custom values that are designated using the anycastPrefix and multicastPrefix parameters within the URL of an acceptor.
+However, clients can specify a special prefix when connecting to an address to
+indicate which kind of routing type to use. The prefixes are custom values that
+are designated using the anycastPrefix and multicastPrefix parameters within
+the URL of an acceptor.
 
 ### Configuring an Anycast Prefix
 
-In `<broker-instance>/etc/broker.xml`, add the `anycastPrefix` to the URL of the desired acceptor. In the example below, the acceptor is configured to use `anycast://` for the `anycastPrefix`. Client code can specify `anycast://foo/` if the client needs to send a message to only one of the `ANYCAST` queues.
+In `<broker-instance>/etc/broker.xml`, add the `anycastPrefix` to the URL of
+the desired acceptor. In the example below, the acceptor is configured to use
+`anycast://` for the `anycastPrefix`. Client code can specify `anycast://foo/`
+if the client needs to send a message to only one of the `ANYCAST` queues.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-      <acceptors>
-         <acceptor name="artemis">tcp://0.0.0.0:61616?protocols=AMQP;anycastPrefix=anycast://</acceptor>
-      </acceptors>
-    ...
-  </core>
-</configuration>
+<acceptor name="artemis">tcp://0.0.0.0:61616?protocols=AMQP;anycastPrefix=anycast://</acceptor>
 ```
 
 ### Configuring a Multicast Prefix
 
-In `<broker-instance>/etc/broker.xml`, add the `multicastPrefix` to the URL of the desired acceptor. In the example below, the acceptor is configured to use `multicast://` for the `multicastPrefix`. Client code can specify `multicast://foo/` if the client needs to send a message to only one of the `MULTICAST` queues.
+In `<broker-instance>/etc/broker.xml`, add the `multicastPrefix` to the URL of
+the desired acceptor. In the example below, the acceptor is configured to use
+`multicast://` for the `multicastPrefix`. Client code can specify
+`multicast://foo/` if the client needs to send a message to only one of the
+`MULTICAST` queues.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-      <acceptors>
-         <acceptor name="artemis">tcp://0.0.0.0:61616?protocols=AMQP;multicastPrefix=multicast://</acceptor>
-      </acceptors>
-    ...
-  </core>
-</configuration>
+<acceptor name="artemis">tcp://0.0.0.0:61616?protocols=AMQP;multicastPrefix=multicast://</acceptor>
 ```
 
 ## Advanced Address Configuration
 
 ### Static Subscription Queues
 
-In most cases it’s not necessary to statically configure subscription queues. The relevant protocol managers take care of dynamically creating subscription queues when clients request to subscribe to an address.  The type of subscription queue created depends on what properties the client request.  For example, durable, non-shared, shared etc.  Protocol managers use special queue naming conventions to identify which queues belong to which consumers and users need not worry about the details.
-
-However, there are scenarios where a user may want to use broker side configuration to statically configure a subscription and later connect to that queue directly using a [Fully Qualified Queue name](#fully-qualified-queue-names).  The examples below show how to use broker side configuration to statically configure a queue with publish subscribe behavior for shared, non-shared, durable and non-durable subscription behavior.
+In most cases it’s not necessary to statically configure subscription queues.
+The relevant protocol managers take care of dynamically creating subscription
+queues when clients request to subscribe to an address.  The type of
+subscription queue created depends on what properties the client request.  For
+example, durable, non-shared, shared etc.  Protocol managers use special queue
+naming conventions to identify which queues belong to which consumers and users
+need not worry about the details.
+
+However, there are scenarios where a user may want to use broker side
+configuration to statically configure a subscription and later connect to that
+queue directly using a [Fully Qualified Queue
+name](#fully-qualified-queue-names).  The examples below show how to use broker
+side configuration to statically configure a queue with publish subscribe
+behavior for shared, non-shared, durable and non-durable subscription behavior.
 
 #### Shared, Durable Subscription Queue using max-consumers
 
-The default behavior for queues is to not limit the number connected queue consumers.  The **max-consumers** parameter of the queue element can be used to limit the number of connected consumers allowed at any one time.
+The default behavior for queues is to not limit the number connected queue
+consumers.  The **max-consumers** parameter of the queue element can be used to
+limit the number of connected consumers allowed at any one time.
 
 Open the file `<broker-instance>/etc/broker.xml` for editing.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <address name="durable.foo">
+<addresses>
+   <address name="durable.foo">
       <multicast>
-        <!-- pre-configured shared durable subscription queue -->
-        <queue name="q1" max-consumers="10">
-          <durable>true</durable>
-        </queue>
+         <!-- pre-configured shared durable subscription queue -->
+         <queue name="q1" max-consumers="10">
+            <durable>true</durable>
+         </queue>
       </multicast>
-    </address>
-  </core>
-</configuration>
+   </address>
+</addresses>
 ```
 
 #### Non-shared, Durable Subscription Queue
 
-The broker can be configured to prevent more than one consumer from connecting to a queue at any one time. The subscriptions to queues configured this way are therefore "non-shared".  To do this simply set the **max-consumers** parameter to "1"
+The broker can be configured to prevent more than one consumer from connecting
+to a queue at any one time. The subscriptions to queues configured this way are
+therefore "non-shared".  To do this simply set the **max-consumers** parameter
+to `1`:
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <address name="durable.foo">
+<addresses>
+   <address name="durable.foo">
       <multicast>
-        <!-- pre-configured non shared durable subscription queue -->
-        <queue name="q1" max-consumers="1">
-          <durable>true</durable>
-        </queue>
+         <!-- pre-configured non shared durable subscription queue -->
+         <queue name="q1" max-consumers="1">
+            <durable>true</durable>
+         </queue>
       </multicast>
-    </address>
-  </core>
-</configuration>
+   </address>
+</addresses>
 ```
 
 #### Non-durable Subscription Queue
 
-Non-durable subscriptions are again usually managed by the relevant protocol manager, by creating and deleting temporary queues.
+Non-durable subscriptions are again usually managed by the relevant protocol
+manager, by creating and deleting temporary queues.
 
-If a user requires to pre-create a queue that behaves like a non-durable subscription queue the **purge-on-no-consumers** flag can be enabled on the queue.  When **purge-on-no-consumers** is set to **true**.  The queue will not start receiving messages until a consumer is attached.  When the last consumer is detached from the queue.  The queue is purged (it's messages are removed) and will not receive any more messages until a new consumer is attached.
+If a user requires to pre-create a queue that behaves like a non-durable
+subscription queue the **purge-on-no-consumers** flag can be enabled on the
+queue.  When **purge-on-no-consumers** is set to **true**.  The queue will not
+start receiving messages until a consumer is attached.  When the last consumer
+is detached from the queue.  The queue is purged (it's messages are removed)
+and will not receive any more messages until a new consumer is attached.
 
 Open the file `<broker-instance>/etc/broker.xml` for editing.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <address name="non.shared.durable.foo">
+<addresses>
+   <address name="non.shared.durable.foo">
       <multicast>
-        <queue name="orders1" purge-on-no-consumers="true"/>
+         <queue name="orders1" purge-on-no-consumers="true"/>
       </multicast>
-    </address>
-  </core>
-</configuration>
+   </address>
+</addresses>
 ```
 
 #### Exclusive Consumer Queue
 
-If a user requires to statically configure a queue that routes exclusively to one active consumer the **exclusive** flag can be enabled on the queue.
+If a user requires to statically configure a queue that routes exclusively to
+one active consumer the **exclusive** flag can be enabled on the queue.
   
-When **exclusive** is set to **true** the queue will route messages to the a single active consumer.  When the active consumer that is being routed to is detached from the queue, if another active consumer exist, one will be chosen and routing will now be exclusive to it.
+When **exclusive** is set to **true** the queue will route messages to the a
+single active consumer.  When the active consumer that is being routed to is
+detached from the queue, if another active consumer exist, one will be chosen
+and routing will now be exclusive to it.
 
 See [Exclusive Queue](exclusive-queues.md) for further information.
 
 Open the file `<broker-instance>/etc/broker.xml` for editing.
 
 ```xml
-<configuration ...>
-  <core ...>
-    ...
-    <address name="foo.bar">
+<addresses>
+   <address name="foo.bar">
       <multicast>
-        <queue name="orders1" exclusive="true"/>
+         <queue name="orders1" exclusive="true"/>
       </multicast>
-    </address>
-  </core>
-</configuration>
+   </address>
+</addresses>
 ```
 
 ## Protocol Managers
 
-A "protocol manager" maps protocol-specific concepts down to the core addressing model (using addresses, queues and routing types). For example, when a client sends a MQTT subscription packet with the addresses: 
+A "protocol manager" maps protocol-specific concepts down to the core
+addressing model (using addresses, queues and routing types). For example, when
+a client sends a MQTT subscription packet with the addresses: 
 
 ```
 /house/room1/lights
 /house/room2/lights
 ```
 
-The MQTT protocol manager understands that the two addresses require `MULTICAST` semantics. The protocol manager will therefore first look to ensure that `MULTICAST` is enabled for both addresses. If not, it will attempt to dynamically create them. If successful, the protocol manager will then create special subscription queues with special names, for each subscription requested by the client.
+The MQTT protocol manager understands that the two addresses require
+`MULTICAST` semantics. The protocol manager will therefore first look to ensure
+that `MULTICAST` is enabled for both addresses. If not, it will attempt to
+dynamically create them. If successful, the protocol manager will then create
+special subscription queues with special names, for each subscription requested
+by the client.
 
-The special name allows the protocol manager to quickly identify the required client subscription queues should the client disconnect and reconnect at a later date.  If the subscription is temporary the protocol manager will delete the queue once the client disconnects.  
+The special name allows the protocol manager to quickly identify the required
+client subscription queues should the client disconnect and reconnect at a
+later date.  If the subscription is temporary the protocol manager will delete
+the queue once the client disconnects.
 
-When a client requests to subscribe to a point to point address.  The protocol manager will look up the queue associated with the point to point address.  This queue should have the same name as the addresss.
+When a client requests to subscribe to a point to point address.  The protocol
+manager will look up the queue associated with the point to point address.
+This queue should have the same name as the addresss.
 
-**Note:** If the queue is auto created, it will be auto deleted once there are no consumers and no messages in it.  For more information on auto create see the next section [Configuring Addresses and Queues via Address Settings](#configuring-addresses-and-queues-via-address-settings)
+**Note:** If the queue is auto created, it will be auto deleted once there are
+no consumers and no messages in it.  For more information on auto create see
+the next section [Configuring Addresses and Queues via Address
+Settings](#configuring-addresses-and-queues-via-address-settings)
 
 ## Configuring Addresses and Queues via Address Settings
 
-There are some attributes that are defined against an address wildcard
-rather than a specific address/queue. Here an example of an `address-setting`
-entry that would be found in the `broker.xml` file.
+There are some attributes that are defined against an address wildcard rather
+than a specific address/queue. Here an example of an `address-setting` entry
+that would be found in the `broker.xml` file.
 
 ```xml
 <address-settings>
    <address-setting match="order.foo">
       <dead-letter-address>DLA</dead-letter-address>
-      <max-delivery-attempts>3</max-delivery-attempts>
-      <redelivery-delay>5000</redelivery-delay>
       <expiry-address>ExpiryQueue</expiry-address>
-      <last-value-queue>true</last-value-queue>
+      <expiry-delay>123</expiry-delay>
+      <redelivery-delay>5000</redelivery-delay>
+      <redelivery-delay-multiplier>1.0</redelivery-delay-multiplier>
+      <max-redelivery-delay>10000</max-redelivery-delay>
+      <max-delivery-attempts>3</max-delivery-attempts>
       <max-size-bytes>100000</max-size-bytes>
+      <max-size-bytes-reject-threshold>-1</max-size-bytes-reject-threshold>
       <page-size-bytes>20000</page-size-bytes>
+      <page-max-cache-size></page-max-cache-size>
+      <address-full-policy>PAGE</address-full-policy>
+      <message-counter-history-day-limit></message-counter-history-day-limit>
+      <last-value-queue>true</last-value-queue> <!-- deprecated! see default-last-value-queue -->
+      <default-last-value-queue>true</default-last-value-queue>
+      <default-exclusive-queue></default-exclusive-queue>
       <redistribution-delay>0</redistribution-delay>
       <send-to-dla-on-no-route>true</send-to-dla-on-no-route>
-      <address-full-policy>PAGE</address-full-policy>
       <slow-consumer-threshold>-1</slow-consumer-threshold>
       <slow-consumer-policy>NOTIFY</slow-consumer-policy>
       <slow-consumer-check-period>5</slow-consumer-check-period>
+      <auto-create-jms-queues>true</auto-create-jms-queues> <!-- deprecated! see auto-create-queues -->
+      <auto-delete-jms-queues>true</auto-delete-jms-queues> <!-- deprecated! see auto-delete-queues -->
+      <auto-create-jms-topics>true</auto-create-jms-topics> <!-- deprecated! see auto-create-addresses -->
+      <auto-delete-jms-topics>true</auto-delete-jms-topics> <!-- deprecated! see auto-delete-addresses -->
+      <auto-create-queues>true</auto-create-queues>
+      <auto-delete-queues>true</auto-delete-queues>
+      <config-delete-queues>OFF</config-delete-queues>
+      <auto-create-addresses>true</auto-create-addresses>
+      <auto-delete-addresses>true</auto-delete-addresses>
+      <config-delete-addresses>OFF</config-delete-addresses>
+      <management-browse-page-size>200</management-browse-page-size>
+      <default-purge-on-no-consumers>false</default-purge-on-no-consumers>
+      <default-max-consumers>-1</default-max-consumers>
+      <default-queue-routing-type></default-queue-routing-type>
+      <default-address-routing-type></default-address-routing-type>
    </address-setting>
 </address-settings>
 ```
 
-The idea with address settings, is you can provide a block of settings
-which will be applied against any addresses that match the string in the
-`match` attribute. In the above example the settings would only be
-applied to the address "order.foo" address but you can also use wildcards
-to apply settings.  See: [The chapter on the wild card syntax](wildcard-syntax.md).
-
-For example, if you used the `match` string `queue.#` the settings
-would be applied to all addresses which start with `queue.`
-
-The meaning of the specific settings are explained fully throughout the
-user manual, however here is a brief description with a link to the
-appropriate chapter if available.
+The idea with address settings, is you can provide a block of settings which
+will be applied against any addresses that match the string in the `match`
+attribute. In the above example the settings would only be applied to the
+address "order.foo" address but you can also use
+[wildcards](wildcard-syntax.md) to apply settings.
+
+For example, if you used the `match` string `queue.#` the settings would be
+applied to all addresses which start with `queue.`
+
+The meaning of the specific settings are explained fully throughout the user
+manual, however here is a brief description with a link to the appropriate
+chapter if available.
+
+`dead-letter-address` is the address to which messages are sent when they
+exceed `max-delivery-attempts`. If no address is defined here then such
+messages will simply be discarded. Read more about [undelivered
+messages](undelivered-messages.md#configuring-dead-letter-addresses).
+
+`expiry-address` defines where to send a message that has expired. If no
+address is defined here then such messages will simply be discarded. Read more
+about [message expiry](message-expiry.md#configuring-expiry-addresses).
+
+`expiry-delay` defines the expiration time that will be used for messages which
+are using the default expiration time (i.e. 0). For example, if `expiry-delay`
+is set to "10" and a message which is using the default expiration time (i.e.
+0) arrives then its expiration time of "0" will be changed to "10." However, if
+a message which is using an expiration time of "20" arrives then its expiration
+time will remain unchanged. Setting `expiry-delay` to "-1" will disable this
+feature. The default is "-1". Read more about [message
+expiry](message-expiry.md#configuring-expiry-addresses).
 
 `max-delivery-attempts` defines how many time a cancelled message can be
-redelivered before sending to the `dead-letter-address`. A full
-explanation can be found [here](undelivered-messages.md#configuring-dead-letter-addresses).
-
-`redelivery-delay` defines how long to wait before attempting redelivery
-of a cancelled message. see [here](undelivered-messages.md#configuring-delayed-redelivery).
-
-`expiry-address` defines where to send a message that has expired. see
-[here](message-expiry.md#configuring-expiry-addresses).
-
-`expiry-delay` defines the expiration time that will be used for
-messages which are using the default expiration time (i.e. 0). For
-example, if `expiry-delay` is set to "10" and a message which is using
-the default expiration time (i.e. 0) arrives then its expiration time of
-"0" will be changed to "10." However, if a message which is using an
-expiration time of "20" arrives then its expiration time will remain
-unchanged. Setting `expiry-delay` to "-1" will disable this feature. The
-default is "-1".
-
-`last-value-queue` defines whether a queue only uses last values or not.
-see [here](last-value-queues.md).
-
-`max-size-bytes` and `page-size-bytes` are used to set paging on an
-address. This is explained [here](paging.md#configuration).
-
-`redistribution-delay` defines how long to wait when the last consumer
-is closed on a queue before redistributing any messages. see
-[here](clusters.md#message-redistribution).
-
-`send-to-dla-on-no-route`. If a message is sent to an address, but the
-server does not route it to any queues, for example, there might be no
-queues bound to that address, or none of the queues have filters that
-match, then normally that message would be discarded. However if this
-parameter is set to true for that address, if the message is not routed
-to any queues it will instead be sent to the dead letter address (DLA)
-for that address, if it exists.
-
-`address-full-policy`. This attribute can have one of the following
-values: PAGE, DROP, FAIL or BLOCK and determines what happens when an
-address where `max-size-bytes` is specified becomes full. The default
-value is PAGE. If the value is PAGE then further messages will be paged
-to disk. If the value is DROP then further messages will be silently
-dropped. If the value is FAIL then further messages will be dropped and
-an exception will be thrown on the client-side. If the value is BLOCK
-then client message producers will block when they try and send further
-messages. See the following chapters for more info [Flow Control](flow-control.md), [Paging](paging.md).
-
-`slow-consumer-threshold`. The minimum rate of message consumption
-allowed before a consumer is considered "slow." Measured in
-messages-per-second. Default is -1 (i.e. disabled); any other valid
-value must be greater than 0.
-
-`slow-consumer-policy`. What should happen when a slow consumer is
-detected. `KILL` will kill the consumer's connection (which will
-obviously impact any other client threads using that same connection).
-`NOTIFY` will send a CONSUMER\_SLOW management notification which an
-application could receive and take action with. See [slow consumers](slow-consumers.md) for more details
-on this notification.
+redelivered before sending to the `dead-letter-address`. Read more about
+[undelivered
+messages](undelivered-messages.md#configuring-dead-letter-addresses).
+
+`redelivery-delay` defines how long to wait before attempting redelivery of a
+cancelled message. Default is `0`. Read more about [undelivered
+messages](undelivered-messages.md#configuring-delayed-redelivery).
+
+`redelivery-delay-multiplier` defines the number by which the
+`redelivery-delay` will be multiplied on each subsequent redelivery attempt.
+Default is `1.0`. Read more about [undelivered
+messages](undelivered-messages.md#configuring-delayed-redelivery).
+
+`max-size-bytes`, `page-size-bytes`, & `page-max-cache-size` are used to
+configure paging on an address. This is explained
+[here](paging.md#configuration).
+
+`max-size-bytes-reject-threshold` is used with the address full `BLOCK` policy,
+the maximum size (in bytes) an address can reach before messages start getting
+rejected. Works in combination with `max-size-bytes` **for AMQP clients only**.
+Default is `-1` (i.e. no limit).
+
+`address-full-policy`. This attribute can have one of the following values:
+`PAGE`, `DROP`, `FAIL` or `BLOCK` and determines what happens when an address
+where `max-size-bytes` is specified becomes full. The default value is `PAGE`.
+If the value is `PAGE` then further messages will be paged to disk. If the
+value is `DROP` then further messages will be silently dropped. If the value is
+`FAIL` then further messages will be dropped and an exception will be thrown on
+the client-side. If the value is `BLOCK` then client message producers will
+block when they try and send further messages.  See the [Flow
+Control](flow-control.md) and [Paging](paging.md) chapters for more info.
+
+`message-counter-history-day-limit` is the number of days to keep message
+counter history for this address assuming that `message-counter-enabled` is
+`true`. Default is `0`.
+
+`last-value-queue` is **deprecated**. See `default-last-value-queue`. It
+defines whether a queue only uses last values or not. Default is `false`. Read
+more about [last value queues](last-value-queues.md).
+
+`default-last-value-queue` defines whether a queue only uses last values or
+not. Default is `false`. This value can be overridden at the queue level using
+the `last-value` boolean. Read more about [last value
+queues](last-value-queues.md).
+
+`default-exclusive-queue` defines whether a queue will serve only a single
+consumer. Default is `false`. This value can be overridden at the queue level
+using the `exclusive` boolean. Read more about [exclusive
+queues](exclusive-queues.md).
+
+`redistribution-delay` defines how long to wait when the last consumer is
+closed on a queue before redistributing any messages. Read more about
+[clusters](clusters.md#message-redistribution).
+
+`send-to-dla-on-no-route`. If a message is sent to an address, but the server
+does not route it to any queues (e.g. there might be no queues bound to that
+address, or none of the queues have filters that match) then normally that
+message would be discarded. However, if this parameter is `true` then such a
+message will instead be sent to the `dead-letter-address` (DLA) for that
+address, if it exists.
+
+`slow-consumer-threshold`. The minimum rate of message consumption allowed
+before a consumer is considered "slow." Measured in messages-per-second.
+Default is `-1` (i.e. disabled); any other valid value must be greater than 0.
+Read more about [slow consumers](slow-consumers.md).
+
+`slow-consumer-policy`. What should happen when a slow consumer is detected.
+`KILL` will kill the consumer's connection (which will obviously impact any
+other client threads using that same connection). `NOTIFY` will send a
+CONSUMER\_SLOW management notification which an application could receive and
+take action with. Read more about [slow consumers](slow-consumers.md).
 
 `slow-consumer-check-period`. How often to check for slow consumers on a
-particular queue. Measured in seconds. Default is 5. See [slow consumers](slow-consumers.md)
-for more information about slow consumer detection.
-
-`auto-create-jms-queues`. Whether or not the broker should automatically
-create a JMS queue when a JMS message is sent to a queue whose name fits
-the address `match` (remember, a JMS queue is just a core queue which has
-the same address and queue name) or a JMS consumer tries to connect to a
-queue whose name fits the address `match`. Queues which are auto-created
-are durable, non-temporary, and non-transient. Default is `true`. This is
-_DEPRECATED_.  See `auto-create-queues`.
-
-`auto-delete-jms-queues`. Whether or not the broker should automatically
-delete auto-created JMS queues when they have both 0 consumers and 0 messages.
-Default is `true`. This is _DEPRECATED_.  See `auto-delete-queues`.
-
-`auto-create-jms-topics`. Whether or not the broker should automatically
-create a JMS topic when a JMS message is sent to a topic whose name fits
-the address `match` (remember, a JMS topic is just a core address which has 
-one or more core queues mapped to it) or a JMS consumer tries to subscribe
-to a topic whose name fits the address `match`. Default is `true`. This is
-_DEPRECATED_.  See `auto-create-addresses`.
-
-`auto-delete-jms-topics`. Whether or not the broker should automatically
-delete auto-created JMS topics once the last subscription on the topic has
-been closed. Default is `true`. This is _DEPRECATED_.  See `auto-delete-addresses`.
-
-`auto-create-queues`. Whether or not the broker should automatically
-create a queue when a message is sent or a consumer tries to connect to a
-queue whose name fits the address `match`. Queues which are auto-created
-are durable, non-temporary, and non-transient. Default is `true`.
-
-`auto-delete-queues`. Whether or not the broker should automatically
-delete auto-created queues when they have both 0 consumers and 0 messages.
-Default is `true`.
-
-`config-delete-queues`. How the broker should handle queues deleted
-on config reload, by delete policy: `OFF` or `FORCE`.
-See [config-reload](config-reload.md) for more details.
-Default is `OFF`.
-
-`auto-create-addresses`. Whether or not the broker should automatically
-create an address when a message is sent to or a consumer tries to consume
-from a queue which is mapped to an address whose name fits the address `match`.
-Default is `true`.
-
-`auto-delete-addresses`. Whether or not the broker should automatically
-delete auto-created addresses once the address no longer has any queues.
+particular queue. Measured in *seconds*. Default is `5`. Read more about [slow
+consumers](slow-consumers.md).
+
+`auto-create-jms-queues` is **deprecated**. See `auto-create-queues`. Whether
+or not the broker should automatically create a JMS queue when a JMS message is
+sent to a queue whose name fits the address `match` (remember, a JMS queue is
+just a core queue which has the same address and queue name) or a JMS consumer
+tries to connect to a queue whose name fits the address `match`. Queues which
+are auto-created are durable, non-temporary, and non-transient. Default is
+`true`.
+
+`auto-delete-jms-queues` is **deprecated**. See `auto-delete-queues`. Whether
+or not the broker should automatically delete auto-created JMS queues when they
+have both 0 consumers and 0 messages. Default is `true`.
+
+`auto-create-jms-topics` is **deprecated**. See `auto-create-addresses`.
+Whether or not the broker should automatically create a JMS topic when a JMS
+message is sent to a topic whose name fits the address `match` (remember, a JMS
+topic is just a core address which has one or more core queues mapped to it) or
+a JMS consumer tries to subscribe to a topic whose name fits the address
+`match`. Default is `true`.
+
+`auto-delete-jms-topics` is **deprecated**. See `auto-delete-addresses`.
+Whether or not the broker should automatically delete auto-created JMS topics
+once the last subscription on the topic has been closed. Default is `true`.
+
+`auto-create-queues`. Whether or not the broker should automatically create a
+queue when a message is sent or a consumer tries to connect to a queue whose
+name fits the address `match`. Queues which are auto-created are durable,
+non-temporary, and non-transient. Default is `true`.
+
+`auto-delete-queues`. Whether or not the broker should automatically delete
+auto-created queues when they have both 0 consumers and 0 messages. Default is
+`true`.
+
+`config-delete-queues`. How the broker should handle queues deleted on config
+reload, by delete policy: `OFF` or `FORCE`.  Default is `OFF`. Read more about
+[configuration reload](config-reload.md).
+
+`auto-create-addresses`. Whether or not the broker should automatically create
+an address when a message is sent to or a consumer tries to consume from a
+queue which is mapped to an address whose name fits the address `match`.
 Default is `true`.
 
-`config-delete-addresses`. How the broker should handle addresses deleted
-on config reload, by delete policy: `OFF` or `FORCE`.
-See [config-reload](config-reload.md) for more details.
-Default is `OFF`.
\ No newline at end of file
+`auto-delete-addresses`. Whether or not the broker should automatically delete
+auto-created addresses once the address no longer has any queues. Default is
+`true`.
+
+`config-delete-addresses`. How the broker should handle addresses deleted on
+config reload, by delete policy: `OFF` or `FORCE`. Default is `OFF`. Read more
+about [configuration reload](config-reload.md).
+
+`management-browse-page-size` is the number of messages a management resource
+can browse. This is relevant for the "browse" management method exposed on the
+queue control. Default is `200`.
+
+`default-purge-on-no-consumers` defines a queue's default
+`purge-on-no-consumers` setting if none is provided on the queue itself.
+Default is `false`. This value can be overridden at the queue level using the
+`purge-on-no-consumers` boolean. Read more about [this
+functionality](#non-durable-subscription-queue).
+
+`default-max-consumers` defines a queue's default `max-consumers` setting if
+none is provided on the  queue itself.  Default is `-1` (i.e. no limit). This
+value can be overridden at the queue level using the `max-consumers` boolean.
+Read more about [this
+functionality](#shared-durable-subscription-queue-using-max-consumers).
+
+`default-queue-routing-type` defines the routing-type for an auto-created queue
+if the broker is unable to determine the routing-type based on the client
+and/or protocol semantics. Default is `MULTICAST`. Read more about [routing
+types](#routing-type).
+
+`default-address-routing-type` defines the routing-type for an auto-created
+address if the broker is unable to determine the routing-type based on the
+client and/or protocol semantics. Default is `MULTICAST`. Read more about
+[routing types](#routing-type).


Mime
View raw message