Modularize Dispatch Router doc. This closes #661.
diff --git a/docs/books/assemblies/user-guide/configuring-authorization.adoc b/docs/books/assemblies/user-guide/configuring-authorization.adoc
new file mode 100644
index 0000000..185e580
--- /dev/null
+++ b/docs/books/assemblies/user-guide/configuring-authorization.adoc
@@ -0,0 +1,44 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// book.adoc
+
+[id='configuring-authorization-{context}']
+= Configuring authorization
+
+You can configure _policies_ to secure messaging resources in your messaging environment. Policies ensure that only authorized users can access messaging endpoints through the router network, and that the resources on those endpoints are used in an authorized way.
+
+* xref:types-policies-{context}[]
+* xref:how-policies-enforce-connection-resource-limits-{context}[]
+* xref:setting-global-connection-limits-{context}[]
+* xref:setting-connection-resource-limits-messaging-endpoints-{context}[]
+
+// Types of policies
+include::../../modules/user-guide/types-policies.adoc[leveloffset=+1]
+
+// How policies enforce connection and resources limits
+include::../../modules/user-guide/how-policies-enforce-connection-resource-limits.adoc[leveloffset=+1]
+
+// Creating global policies
+include::../../modules/user-guide/setting-global-connection-limits.adoc[leveloffset=+1]
+
+// Creating vhost policies
+include::setting-connection-resource-limits-messaging-endpoints.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/configuring-brokered-messaging.adoc b/docs/books/assemblies/user-guide/configuring-brokered-messaging.adoc
new file mode 100644
index 0000000..066dc04
--- /dev/null
+++ b/docs/books/assemblies/user-guide/configuring-brokered-messaging.adoc
@@ -0,0 +1,41 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// configuring-message-routing.adoc
+
+[id='configuring-brokered-messaging-{context}']
+= Configuring brokered messaging
+
+If you require "store and forward" capabilities, you can configure {RouterName} to use brokered messaging. In this scenario, clients connect to a router to send and receive messages, and the router routes the messages to or from queues on a message broker.
+
+You can configure the following:
+
+* xref:routing-messages-through-broker-queues-{context}[Route messages through broker queues]
++
+You can route messages to a queue hosted on a single broker, or route messages to a _sharded queue_ distributed across multiple brokers.
+
+* xref:handling-undeliverable-messages-{context}[Store and retrieve undeliverable messages on a broker queue]
+
+include::../../modules/user-guide/how-router-enables-brokered-messaging.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/routing-messages-through-broker-queues.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/handling-undeliverable-messages-for-address.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/configuring-logging.adoc b/docs/books/assemblies/user-guide/configuring-logging.adoc
new file mode 100644
index 0000000..d0b4ba9
--- /dev/null
+++ b/docs/books/assemblies/user-guide/configuring-logging.adoc
@@ -0,0 +1,33 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// configuring-router.adoc
+
+[id='configuring-logging-{context}']
+= Configuring logging
+
+{RouterName} contains internal logging modules that provide important information about each router. For each module, you can configure the logging level, the format of the log file, and the location to which the logs should be written.
+
+// Logging modules
+include::../../modules/user-guide/logging-modules.adoc[leveloffset=+1]
+
+// Configuring default logging
+include::../../modules/user-guide/configuring-default-logging.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/configuring-message-routing.adoc b/docs/books/assemblies/user-guide/configuring-message-routing.adoc
new file mode 100644
index 0000000..93c68fc
--- /dev/null
+++ b/docs/books/assemblies/user-guide/configuring-message-routing.adoc
@@ -0,0 +1,50 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// routing-messages-through-router-network.adoc
+
+[id='configuring-message-routing-{context}']
+= Configuring message routing
+
+Message routing is the default routing mechanism. You can use it to route messages on a per-message basis between clients directly (direct-routed messaging), or to and from broker queues (brokered messaging).
+
+With message routing, you can do the following:
+
+* xref:understanding-message-routing-{context}[Understand message routing concepts]
+* xref:configuring-address-semantics-{context}[Configure address semantics (route messages between clients)]
+* xref:configuring-addresses-prioritized-message-delivery-{context}[Configure addresses for prioritized message delivery]
+* xref:configuring-brokered-messaging-{context}[Configure brokered messaging]
+* xref:address-pattern-matching-{context}[Understand address pattern matching]
+
+// Understanding message routing
+include::understanding-message-routing.adoc[leveloffset=+1]
+
+// Configuring address semantics
+include::../../modules/user-guide/configuring-address-semantics.adoc[leveloffset=+1]
+
+// Configuring addresses for prioritized message delivery
+include::../../modules/user-guide/configuring-addresses-prioritized-message-delivery.adoc[leveloffset=+1]
+
+// Configuring brokered messaging
+include::configuring-brokered-messaging.adoc[leveloffset=+1]
+
+// Address pattern matching
+include::../../modules/user-guide/address-pattern-matching.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/configuring-router.adoc b/docs/books/assemblies/user-guide/configuring-router.adoc
index e9b7121..296dff0 100644
--- a/docs/books/assemblies/user-guide/configuring-router.adoc
+++ b/docs/books/assemblies/user-guide/configuring-router.adoc
@@ -31,8 +31,8 @@
* xref:configuring-router-properties-{context}[Configure essential router properties]
* xref:configuring-network-connections-{context}[Configure network connections]
* xref:securing-network-connections-{context}[Secure network connections]
-* xref:authorizing-access-to-messaging-resources[Authorize access to messaging resources]
-* xref:logging[Configure logging]
+* xref:authorizing-access-messaging-resources-{context}[Authorize access to messaging resources]
+* xref:configuring-logging-{context}[Configure logging]
// Configuring router properties
include::../../modules/user-guide/configuring-router-properties.adoc[leveloffset=+1]
@@ -44,4 +44,7 @@
include::securing-network-connections.adoc[leveloffset=+1]
// Authorizing access to messaging resources
-include::../../modules/user-guide/authorization.adoc[leveloffset=+1]
+include::authorizing-access-messaging-resources.adoc[leveloffset=+1]
+
+// Configuring logging
+include::configuring-logging.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/configuring-routing.adoc b/docs/books/assemblies/user-guide/configuring-routing.adoc
new file mode 100644
index 0000000..d9f9546
--- /dev/null
+++ b/docs/books/assemblies/user-guide/configuring-routing.adoc
@@ -0,0 +1,39 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// book.adoc
+
+[id='configuring-routing-{context}']
+= Configuring routing
+
+Routing is the process by which messages are delivered to their destinations. To accomplish this, {RouterName} provides two routing mechanisms: _message routing_ and _link routing_.
+
+xref:configuring-message-routing-{context}[Message routing]::
+Message routing is the default routing mechanism. You can use it to route messages on a per-message basis between clients directly (direct-routed messaging), or to and from broker queues (brokered messaging).
+
+xref:creating-link-routes-{context}[Link routing]::
+A link route represents a private messaging path between a sender and a receiver in which the router passes the messages between end points. You can use it to connect a client to a service (such as a broker queue).
+
+// Configuring the address space for message routing
+include::configuring-message-routing.adoc[leveloffset=+1]
+
+// Creating link routes
+include::creating-link-routes.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/creating-link-routes.adoc b/docs/books/assemblies/user-guide/creating-link-routes.adoc
new file mode 100644
index 0000000..ca06e78
--- /dev/null
+++ b/docs/books/assemblies/user-guide/creating-link-routes.adoc
@@ -0,0 +1,36 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// configuring-routing.adoc
+
+[id='creating-link-routes-{context}']
+= Creating link routes
+
+A link route represents a private messaging path between a sender and a receiver in which the router passes the messages between end points. You can use it to connect a client to a service (such as a broker queue).
+
+// Understanding link routing
+include::understanding-link-routing.adoc[leveloffset=+1]
+
+// Creating a link route
+include::../../modules/user-guide/creating-link-route.adoc[leveloffset=+1]
+
+// Link route example
+include::../../modules/user-guide/link-route-example.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/getting-started.adoc b/docs/books/assemblies/user-guide/getting-started.adoc
index cfb8a92..ce13703 100644
--- a/docs/books/assemblies/user-guide/getting-started.adoc
+++ b/docs/books/assemblies/user-guide/getting-started.adoc
@@ -21,25 +21,22 @@
//
// book.adoc
+ifdef::context[:parent-context: {context}]
+
[id='getting-started-{context}']
= Getting started
-This section shows you how to start the {RouterName} with the default configuration settings, and distribute messages between two clients.
+This section provides a quick introduction to {RouterName} by showing you how to install {RouterName}, start the router with the default configuration settings, and distribute messages between two clients.
-.Prerequisites
+:context: getting-started
+include::../../modules/user-guide/installing-router-linux.adoc[leveloffset=+1]
+ifdef::parent-context[:context: {parent-context}]
+ifndef::parent-context[:!context:]
-* {RouterName} must be installed.
-+
-For more information, see xref:installing-router-{context}[].
+include::../../modules/user-guide/exploring-default-router-configuration-file.adoc[leveloffset=+1]
-// Viewing the default router configuration file
-include::../../modules/user-guide/viewing-default-router-configuration-file.adoc[leveloffset=+1]
-
-// Starting the router
include::../../modules/user-guide/starting-router-getting-started.adoc[leveloffset=+1]
-// Sending some test messages
include::../../modules/user-guide/sending-test-messages.adoc[leveloffset=+1]
-// Next steps
include::../../modules/user-guide/next-steps.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/important-terms-concepts.adoc b/docs/books/assemblies/user-guide/important-terms-concepts.adoc
index d03c21c..7e75b6d 100644
--- a/docs/books/assemblies/user-guide/important-terms-concepts.adoc
+++ b/docs/books/assemblies/user-guide/important-terms-concepts.adoc
@@ -19,7 +19,7 @@
// This assembly is included in the following assemblies:
//
-// overview.adoc
+// book.adoc
[id='important-terms-concepts-{context}']
= Important terms and concepts
@@ -27,13 +27,7 @@
Before using {RouterName}, you should be familiar with AMQP and understand some key concepts about {RouterName}.
include::../../modules/user-guide/overview-of-amqp.adoc[leveloffset=+1]
-
include::../../modules/user-guide/what-routers-are.adoc[leveloffset=+1]
-
-// include::modules/how-routers-connect-endpoints.adoc[leveloffset=+1]
-
include::../../modules/user-guide/how-routers-route-messages.adoc[leveloffset=+1]
-
include::../../modules/user-guide/router-security.adoc[leveloffset=+1]
-
include::../../modules/user-guide/router-management.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/installing-router.adoc b/docs/books/assemblies/user-guide/installing-router.adoc
new file mode 100644
index 0000000..1a44048
--- /dev/null
+++ b/docs/books/assemblies/user-guide/installing-router.adoc
@@ -0,0 +1,51 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// book.adoc
+
+[id='installing-router-{context}']
+= Installing {RouterName}
+
+You can deploy {RouterName} as a single standalone router, or as multiple routers connected together in a router network. Router networks may represent any arbitrary topology, enabling you to design the network to best fit your requirements.
+
+With {RouterName}, the router network topology is independent from the message routing. This means that messaging clients always experience the same message routing behavior regardless of the underlying network topology. Even in a multi-site or hybrid cloud router network, the connected endpoints behave as if they were connected to a single, logical router.
+
+To create the router network topology, complete the following:
+
+. xref:router-deployment-guidelines-{context}[Review the deployment guidelines].
++
+You should understand the different router operating modes you can deploy in your topology, and be aware of security requirements for the interior portion of the router network.
+
+. xref:installing-router-linux-{context}[Install {RouterName} on the host].
++
+If you are creating a router network with multiple routers, repeat this step on each host.
+
+. xref:preparing-router-configurations-{context}[Prepare the router configurations].
++
+After installing {RouterName}, configure it to define how it should connect to other routers and endpoints, and how it should operate.
+
+. xref:starting-router-{context}[Start the routers].
++
+After the routers are configured, start them so that they can connect to each other and begin routing messages.
+
+include::../../modules/user-guide/installing-router-linux.adoc[leveloffset=+1]
+include::../../modules/user-guide/preparing-router-configurations.adoc[leveloffset=+1]
+include::../../modules/user-guide/starting-routers.adoc[leveloffset=+1]
diff --git a/docs/books/modules/user-guide/installing-router.adoc b/docs/books/assemblies/user-guide/managing-router.adoc
similarity index 63%
copy from docs/books/modules/user-guide/installing-router.adoc
copy to docs/books/assemblies/user-guide/managing-router.adoc
index f870357..55d80d6 100644
--- a/docs/books/modules/user-guide/installing-router.adoc
+++ b/docs/books/assemblies/user-guide/managing-router.adoc
@@ -17,15 +17,23 @@
under the License
////
-// Module included in the following assemblies:
+// This assembly is included in the following assemblies:
//
-// getting-started.adoc
+// book.adoc
-[id='installing-router-{context}']
-= Installing {RouterName}
+[id='managing-router-{context}']
+= Managing {RouterName}
-include::{FragmentDir}/fragment-router-install-intro.adoc[]
-.Procedure
-include::{FragmentDir}/fragment-router-install-steps.adoc[]
+// Monitoring using the web console
+include::monitoring-using-web-console.adoc[leveloffset=+1]
+
+// Monitoring using qdstat
+include::monitoring-using-qdstat.adoc[leveloffset=+1]
+
+// Managing routers
+include::managing-routers.adoc[leveloffset=+1]
+
+// Troubleshooting
+include::troubleshooting.adoc[leveloffset=+1]
diff --git a/docs/books/modules/user-guide/installing-router.adoc b/docs/books/assemblies/user-guide/managing-routers.adoc
similarity index 67%
copy from docs/books/modules/user-guide/installing-router.adoc
copy to docs/books/assemblies/user-guide/managing-routers.adoc
index f870357..689fb1f 100644
--- a/docs/books/modules/user-guide/installing-router.adoc
+++ b/docs/books/assemblies/user-guide/managing-routers.adoc
@@ -17,15 +17,17 @@
under the License
////
-// Module included in the following assemblies:
+// This assembly is included in the following assemblies:
//
-// getting-started.adoc
+// managing-router.adoc
-[id='installing-router-{context}']
-= Installing {RouterName}
+[id='managing-routers-{context}']
+= Managing routers
-include::{FragmentDir}/fragment-router-install-intro.adoc[]
-.Procedure
-include::{FragmentDir}/fragment-router-install-steps.adoc[]
+include::../../modules/user-guide/starting-routers.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/changing-router-configuration.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/syntax-using-qdmanage.adoc[leveloffset=+1]
diff --git a/docs/books/modules/user-guide/installing-router.adoc b/docs/books/assemblies/user-guide/monitoring-using-qdstat.adoc
similarity index 63%
copy from docs/books/modules/user-guide/installing-router.adoc
copy to docs/books/assemblies/user-guide/monitoring-using-qdstat.adoc
index f870357..ec96f48 100644
--- a/docs/books/modules/user-guide/installing-router.adoc
+++ b/docs/books/assemblies/user-guide/monitoring-using-qdstat.adoc
@@ -17,15 +17,15 @@
under the License
////
-// Module included in the following assemblies:
+// This assembly is included in the following assemblies:
//
-// getting-started.adoc
+// managing-router.adoc
-[id='installing-router-{context}']
-= Installing {RouterName}
+[id='monitoring-using-qdstat-{context}']
+= Monitoring using `qdstat`
-include::{FragmentDir}/fragment-router-install-intro.adoc[]
+The `qdstat` tool is a command-line tool for monitoring the status and performance of {RouterName} router networks.
-.Procedure
+include::../../modules/user-guide/syntax-using-qdstat.adoc[leveloffset=+1]
-include::{FragmentDir}/fragment-router-install-steps.adoc[]
+include::../../modules/user-guide/commands-monitoring-router-network.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/monitoring-using-web-console.adoc b/docs/books/assemblies/user-guide/monitoring-using-web-console.adoc
new file mode 100644
index 0000000..71f996f
--- /dev/null
+++ b/docs/books/assemblies/user-guide/monitoring-using-web-console.adoc
@@ -0,0 +1,36 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// book.adoc
+
+[id='monitoring-using-web-console'-{context}']
+= Monitoring using {ConsoleName}
+
+{ConsoleName} is a web console for monitoring the status and performance of {RouterName} router networks.
+
+//.Prerequisites
+include::{FragmentDir}/fragment-console-prereq.adoc[]
+
+include::../../modules/user-guide/setting-up-access-web-console.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/accessing-web-console.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/monitoring-router-network-web-console.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/overview.adoc b/docs/books/assemblies/user-guide/overview.adoc
index 0384c11..a422040 100644
--- a/docs/books/assemblies/user-guide/overview.adoc
+++ b/docs/books/assemblies/user-guide/overview.adoc
@@ -21,15 +21,11 @@
//
// book.adoc
-[id='overview-{context}']
-= Overview
+[id='overview-router-{context}']
+= Overview of {RouterName}
{RouterName} is a lightweight AMQP message router for building scalable, available, and performant messaging networks.
include::../../modules/user-guide/key-features.adoc[leveloffset=+1]
-
include::../../modules/user-guide/supported-standards-protocols.adoc[leveloffset=+1]
-
-include::important-terms-concepts.adoc[leveloffset=+1]
-
include::../../common/document_conventions.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/setting-connection-resource-limits-messaging-endpoints.adoc b/docs/books/assemblies/user-guide/setting-connection-resource-limits-messaging-endpoints.adoc
new file mode 100644
index 0000000..48c52a9
--- /dev/null
+++ b/docs/books/assemblies/user-guide/setting-connection-resource-limits-messaging-endpoints.adoc
@@ -0,0 +1,54 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// authorizing-access-messaging-resources.adoc
+
+[id='setting-connection-resource-limits-messaging-endpoints-{context}']
+= Setting connection and resource limits for messaging endpoints
+
+You can define the connection limit and AMQP resource limits for a messaging endpoint by configuring a _vhost policy_. Vhost policies define what resources clients are permitted to access on a messaging endpoint over a particular connection.
+
+[NOTE]
+====
+A vhost is typically the name of the host to which the client connection is directed. For example, if a client application opens a connection to the `amqp://mybroker.example.com:5672/queue01` URL, the vhost would be `mybroker.example.com`.
+====
+
+* xref:enabling-vhost-policies-{context}[]
+* xref:creating-vhost-policies-{context}[]
+* xref:creating-vhost-policies-json-{context}[]
+* xref:setting-resource-limits-outgoing-connections-{context}[]
+* xref:methods-specifying-vhost-policy-source-target-addresses-{context}[]
+* xref:vhost-policy-hostname-pattern-matching-rules-{context}[]
+* xref:vhost-policy-examples-{context}[]
+
+include::../../modules/user-guide/enabling-vhost-policies.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/creating-vhost-policies.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/creating-vhost-policies-json.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/setting-resource-limits-outgoing-connections.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/methods-specifying-vhost-policy-source-target-addresses.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/vhost-policy-hostname-pattern-matching-rules.adoc[leveloffset=+1]
+
+include::../../modules/user-guide/vhost-policy-examples.adoc[leveloffset=+1]
diff --git a/docs/books/modules/user-guide/installing-router.adoc b/docs/books/assemblies/user-guide/troubleshooting.adoc
similarity index 63%
copy from docs/books/modules/user-guide/installing-router.adoc
copy to docs/books/assemblies/user-guide/troubleshooting.adoc
index f870357..25295ec 100644
--- a/docs/books/modules/user-guide/installing-router.adoc
+++ b/docs/books/assemblies/user-guide/troubleshooting.adoc
@@ -17,15 +17,15 @@
under the License
////
-// Module included in the following assemblies:
+// This assembly is included in the following assemblies:
//
-// getting-started.adoc
+// managing-router.adoc
-[id='installing-router-{context}']
-= Installing {RouterName}
+[id='troubleshooting-{context}']
+= Troubleshooting {RouterName}
-include::{FragmentDir}/fragment-router-install-intro.adoc[]
+You can use the {RouterName} logs to diagnose and troubleshoot error and performance issues with the routers in your router network.
-.Procedure
+include::../../modules/user-guide/viewing-log-entries.adoc[leveloffset=+1]
-include::{FragmentDir}/fragment-router-install-steps.adoc[]
+include::../../modules/user-guide/troubleshooting-using-logs.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/understanding-link-routing.adoc b/docs/books/assemblies/user-guide/understanding-link-routing.adoc
new file mode 100644
index 0000000..aa89519
--- /dev/null
+++ b/docs/books/assemblies/user-guide/understanding-link-routing.adoc
@@ -0,0 +1,32 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// configuring-link-routing.adoc
+
+[id='understanding-link-routing-{context}']
+= Understanding link routing
+Link routing provides an alternative strategy for brokered messaging. A link route represents a private messaging path between a sender and a receiver in which the router passes the messages between end points. You can think of a link route as a "virtual connection" or "tunnel" that travels from a sender, through the router network, to a receiver.
+
+With link routing, routing is performed on link-attach frames, which are chained together to form a virtual messaging path that directly connects a sender and receiver. Once a link route is established, the transfer of message deliveries, flow frames, and dispositions is performed across the link route.
+
+include::../../modules/user-guide/link-routing-flow-control.adoc[leveloffset=+1]
+include::../../modules/user-guide/link-route-addresses.adoc[leveloffset=+1]
+include::../../modules/user-guide/routing-patterns-link-routing.adoc[leveloffset=+1]
diff --git a/docs/books/assemblies/user-guide/understanding-message-routing.adoc b/docs/books/assemblies/user-guide/understanding-message-routing.adoc
new file mode 100644
index 0000000..64d8343
--- /dev/null
+++ b/docs/books/assemblies/user-guide/understanding-message-routing.adoc
@@ -0,0 +1,39 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// configuring-address-space-message-routing.adoc
+
+[id='understanding-message-routing-{context}']
+= Understanding message routing
+
+With message routing, routing is performed on messages as producers send them to a router. When a message arrives on a router, the router routes the message and its _settlement_ based on the message’s _address_ and _routing pattern_.
+
+// Message routing flow control
+include::../../modules/user-guide/message-routing-flow-control.adoc[leveloffset=+1]
+
+// Addresses
+include::../../modules/user-guide/addresses-message-routing.adoc[leveloffset=+1]
+
+// Routing patterns
+include::../../modules/user-guide/routing-patterns-message-routing.adoc[leveloffset=+1]
+
+// Message settlement and reliability
+include::../../modules/user-guide/message-settlement-reliability-message-routing.adoc[leveloffset=+1]
diff --git a/docs/books/common/attributes.adoc b/docs/books/common/attributes.adoc
index cf47244..b372d19 100644
--- a/docs/books/common/attributes.adoc
+++ b/docs/books/common/attributes.adoc
@@ -20,7 +20,7 @@
// Standard document attributes
:data-uri!:
-:doctype: article
+:doctype: book
:experimental:
:idprefix:
:imagesdir: images
@@ -39,6 +39,7 @@
:RouterLongName: {ProductName} Dispatch Router
:ClientAmqpPythonName: {ProductName} Proton Python
:ConsoleName: {RouterLongName} Console
+:RouterPlatform: Linux
:FragmentDir: ../../common
:RouterName: Dispatch Router
:RouterSchemaDir: ../../build/doc/book
diff --git a/docs/books/common/fragment-pattern-matching-definition.adoc b/docs/books/common/fragment-pattern-matching-definition.adoc
new file mode 100644
index 0000000..ceb2a99
--- /dev/null
+++ b/docs/books/common/fragment-pattern-matching-definition.adoc
@@ -0,0 +1,30 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
++
+A _pattern_ matches an address that corresponds to a pattern. A pattern is a sequence of words delimited by either a `.` or `/` character. You can use wildcard characters to represent a word. The `*` character matches exactly one word, and the `#` character matches any sequence of zero or more words.
++
+The `*` and `#` characters are reserved as wildcards. Therefore, you should not use them in the message address.
++
+For more information about creating address patterns, see xref:address-pattern-matching-{context}[].
++
+[NOTE]
+====
+You can convert a `prefix` value to a `pattern` by appending `/\#` to it. For example, the prefix `a/b/c` is equivalent to the pattern `a/b/c/#`.
+====
diff --git a/docs/books/modules/user-guide/installing-router.adoc b/docs/books/common/fragment-prefix-matching-definition.adoc
similarity index 71%
copy from docs/books/modules/user-guide/installing-router.adoc
copy to docs/books/common/fragment-prefix-matching-definition.adoc
index f870357..84da9c1 100644
--- a/docs/books/modules/user-guide/installing-router.adoc
+++ b/docs/books/common/fragment-prefix-matching-definition.adoc
@@ -17,15 +17,5 @@
under the License
////
-// Module included in the following assemblies:
-//
-// getting-started.adoc
-
-[id='installing-router-{context}']
-= Installing {RouterName}
-
-include::{FragmentDir}/fragment-router-install-intro.adoc[]
-
-.Procedure
-
-include::{FragmentDir}/fragment-router-install-steps.adoc[]
++
+A _prefix_ matches either an exact address or the beginning segment within an address that is delimited by either a `.` or `/` character. For example, the prefix `my_address` would match the address `my_address` as well as `my_address.1` and `my_address/1`. However, it would not match `my_address1`.
diff --git a/docs/books/common/fragment-router-sasl-para.adoc b/docs/books/common/fragment-router-sasl-para.adoc
index c6264e4..9274542 100644
--- a/docs/books/common/fragment-router-sasl-para.adoc
+++ b/docs/books/common/fragment-router-sasl-para.adoc
@@ -17,4 +17,4 @@
under the License
////
-To see a list of Cyrus SASL plugins in a `dnf`-based Linux system, use the `dnf search cyrus-sasl` command. To install a Cyrus SASL plugin, use the `dnf install _PLUGIN_` command.
+To see a list of Cyrus SASL plugins in a `dnf`-based Linux system, use the `dnf search cyrus-sasl` command. To install a Cyrus SASL plugin, use the `dnf install _<plugin>_` command.
diff --git a/docs/books/modules/user-guide/installing-router.adoc b/docs/books/common/fragment-supported-standards-additional-resources.adoc
similarity index 73%
copy from docs/books/modules/user-guide/installing-router.adoc
copy to docs/books/common/fragment-supported-standards-additional-resources.adoc
index f870357..de02401 100644
--- a/docs/books/modules/user-guide/installing-router.adoc
+++ b/docs/books/common/fragment-supported-standards-additional-resources.adoc
@@ -17,15 +17,5 @@
under the License
////
-// Module included in the following assemblies:
-//
-// getting-started.adoc
-
-[id='installing-router-{context}']
-= Installing {RouterName}
-
-include::{FragmentDir}/fragment-router-install-intro.adoc[]
-
-.Procedure
-
-include::{FragmentDir}/fragment-router-install-steps.adoc[]
+* link:http://www.amqp.org/resources/download[OASIS AMQP 1.0 Specification].
+* For more information about how {RouterName} applies AMQP, see xref:amqp-mapping-{context}[].
diff --git a/docs/books/common/fragment-supported-standards-protocols-list.adoc b/docs/books/common/fragment-supported-standards-protocols-list.adoc
new file mode 100644
index 0000000..85e5dfb
--- /dev/null
+++ b/docs/books/common/fragment-supported-standards-protocols-list.adoc
@@ -0,0 +1,35 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+* Version 1.0 of the Advanced Message Queueing Protocol (AMQP)
+* Modern TCP with IPv6
+* Client compatibility
++
+--
+{RouterName} should, in theory, work with any client that is compatible with AMQP 1.0. The following clients have been tested:
+
+qpid::messaging::
+The Qpid messaging clients work with {RouterName} as long as they are configured to use the 1.0 version of the protocol. To enable AMQP 1.0 in the C++ client, use the `\{protocol:amqp1.0}` connection option.
+
+Proton Reactor::
+The Proton Reactor API is compatible with {RouterName}.
+
+Proton Messenger::
+Messenger works with {RouterName}.
+--
diff --git a/docs/books/modules/user-guide/accessing-web-console.adoc b/docs/books/modules/user-guide/accessing-web-console.adoc
new file mode 100644
index 0000000..5bf4129
--- /dev/null
+++ b/docs/books/modules/user-guide/accessing-web-console.adoc
@@ -0,0 +1,45 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// monitoring-using-web-console.adoc
+
+[id='accessing-web-console'-{context}']
+= Accessing {ConsoleName}
+
+You can access the web console from a web browser.
+
+.Procedure
+
+. In a web browser, navigate to the web console URL.
++
+--
+The web console URL is the _<host>_:__<port>__ from the `listener` that you created to serve the web console. For example: `localhost:8672`.
+
+The {ConsoleName} opens. If you set up user name and password authentication, the *Connect* tab is displayed.
+--
+
+. If necessary, log in to the web console.
++
+--
+If you set up user name and password authentication, enter your user name and password to access the web console.
+
+The syntax for the user name is <__user__>@<__domain__>. For example: `admin@my-domain`.
+--
diff --git a/docs/books/modules/user-guide/address-pattern-matching.adoc b/docs/books/modules/user-guide/address-pattern-matching.adoc
new file mode 100644
index 0000000..1fbf606
--- /dev/null
+++ b/docs/books/modules/user-guide/address-pattern-matching.adoc
@@ -0,0 +1,90 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// configuring-address-space-message-routing.adoc
+
+[id='address-pattern-matching-{context}']
+= Address pattern matching
+
+In some router configuration scenarios, you might need to use pattern matching to match a range of addresses rather than a single, literal address. Address patterns match any address that corresponds to the pattern.
+
+An address pattern is a sequence of tokens (typically words) that are delimited by either `.` or `/` characters. They also can contain special wildcard characters that represent words:
+
+* `*` represents exactly one word
+* `#` represents zero or more words
+
+.Address pattern
+====
+This address contains two tokens, separated by the `/` delimiter:
+
+`my/address`
+====
+
+.Address pattern with wildcard
+====
+This address contains three tokens. The `*` is a wildcard, representing any single word that might be between `my` and `address`:
+
+`my/*/address`
+====
+
+The following table shows some address patterns and examples of the addresses that would match them:
+
+[options="header"]
+|===
+| This pattern... | Matches... | But not...
+
+a| `news/*`
+a| `news/europe`
+
+`news/usa`
+a| `news`
+
+`news/usa/sports`
+
+a| `news/#`
+a| `news`
+
+`news/europe`
+
+`news/usa/sports`
+a| `europe`
+
+`usa`
+
+a| `news/europe/#`
+a| `news/europe`
+
+`news/europe/sports`
+
+`news/europe/politics/fr`
+a| `news/usa`
+
+`europe`
+
+a| `news/*/sports`
+a| `news/europe/sports`
+
+`news/usa/sports`
+a| `news`
+
+`news/europe/fr/sports`
+
+|===
diff --git a/docs/books/modules/user-guide/addresses-message-routing.adoc b/docs/books/modules/user-guide/addresses-message-routing.adoc
new file mode 100644
index 0000000..8149b17
--- /dev/null
+++ b/docs/books/modules/user-guide/addresses-message-routing.adoc
@@ -0,0 +1,43 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// understanding-message-routing.adoc
+
+[id='addresses-message-routing-{context}']
+= Addresses
+
+Addresses determine how messages flow through your router network. An address designates an endpoint in your messaging network, such as:
+
+* Endpoint processes that consume data or offer a service
+* Topics that match multiple consumers to multiple producers
+* Entities within a messaging broker:
+** Queues
+** Durable Topics
+** Exchanges
+
+When a router receives a message, it uses the message's address to determine where to send the message (either its destination or one step closer to its destination).
+
+{RouterName} considers addresses to be _mobile_ in that any user of an address may be directly connected to any router in the router network and may even
+move around the topology. In cases where messages are broadcast to or
+balanced across multiple consumers, the users of the address may be connected to multiple routers in the network.
+
+Mobile addresses may be discovered during normal router operation or
+configured through management settings.
diff --git a/docs/books/modules/user-guide/amqp-mapping.adoc b/docs/books/modules/user-guide/amqp-mapping.adoc
new file mode 100644
index 0000000..21cb37e
--- /dev/null
+++ b/docs/books/modules/user-guide/amqp-mapping.adoc
@@ -0,0 +1,129 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// overview.adoc
+
+[id='amqp-mapping-{context}']
+= AMQP mapping
+
+{RouterName} is an AMQP router and as such, it provides extensions,
+code-points, and semantics for routing over AMQP. This section describes the
+details of {RouterName}'s use of AMQP.
+
+[discrete]
+== Message annotations
+
+The following message annotation fields are defined by {RouterName}:
+
+[options="header"]
+|===
+| Field | Type | Description
+
+|`x-opt-qd.ingress` |string |The identity of the ingress router for a
+message-routed message. The ingress router is the first router
+encountered by a transiting message. The router will, if this field is
+present, leave it unaltered. If the field is not present, the router
+will insert the field with its own identity.
+
+|`x-opt-qd.trace` |list of string |The list of routers through which this
+message-routed message has transited. If this field is not present, the
+router will do nothing. If the field is present, the router will
+append its own identity to the end of the list.
+
+|`x-opt-qd.to` |string |To-override for message-routed messages. If this
+field is present, the address in this field will be used for routing instead of the `to` field in the message properties. A router may append,
+remove, or modify this annotation field depending on the policy in place
+for routing the message.
+
+|`x-opt-qd.phase` |integer |The address-phase, if not zero, for messages
+flowing between routers.
+
+|===
+
+[discrete]
+== Source and target capabilities
+
+The following capability values are used in sources and targets:
+
+`qd.router`::
+This capability is added to sources and targets that are used for inter-router message exchange. This capability denotes a link used for router-control messages flowing between routers.
+
+`qd.router-data`::
+This capability is added to sources and targets that are used for inter-router message exchange. This capability denotes a link used for user messages being message-routed across an inter-router connection.
+
+[discrete]
+== Dynamic node properties
+
+The following dynamic node properties are used by {RouterName} in sources:
+
+`x-opt-qd.address`::
+The node address describing the destination desired for a dynamic source. If this is absent, the router will terminate any dynamic receivers. If this address is present, the router will use the address to route the dynamic link attach to the proper destination container.
+
+[discrete]
+== Addresses and address formats
+
+The following AMQP addresses and address patterns are used within
+{RouterName}:
+
+.Address patterns
+--
+`_local/<addr>`::
+An address that references a locally-attached endpoint. Messages using this address pattern will not be routed over more than one link.
+
+`_topo/0/<router>/<addr>`::
+An address that references an endpoint attached to a specific router node in the network topology. Messages with addresses that follow this pattern shall be routed along the shortest path to the specified router. Addresses of this form are always routable in that the address itself contains enough information to route the message to its destination.
++
+The `0` component immediately preceding the router ID is a placeholder for an _area_ which may be used in the future if area routing is implemented.
+
+`<addr>`::
+A mobile address. An address of this format represents an endpoint or a set of distinct endpoints that are attached to the network in arbitrary locations. It is the responsibility of the router network to determine which router nodes are valid destinations for mobile addresses.
+--
+
+.Supported addresses
+--
+`$management`::
+The management agent on the attached router/container. This address would be used by an endpoint that is a management client/console/tool wishing to access management data from the attached container.
+
+`_topo/0/Router.E/$management`::
+The management agent at Router.E in area 0. This address would be used by a management client wishing to access management data from a specific container that is reachable within the network.
+
+`_local/qdhello`::
+The router entity in each of the connected routers. This address is used to communicate with neighbor routers and is exclusively for the `HELLO` discovery protocol.
+
+`_local/qdrouter`::
+The router entity in each of the connected routers. This address is used by a router to communicate with other routers in the network.
+
+`_topo/0/Router.E/qdrouter`::
+The router entity at the specifically-indicated router. This address form is used by a router to communicate with a specific router that may or may not be a neighbor.
+--
+
+[discrete]
+== Implementation of the AMQP Management specification
+
+{RouterName} is manageable remotely by AMQP. It is compliant with the emerging AMQP Management specification (draft 9) with the following differences:
+
+* The `name` attribute is not required when an entity is created. If not supplied, it will be set to the same value as the system-generated `identity` attribute. Otherwise, it is treated as per the standard.
+
+* The `REGISTER` and `DEREGISTER` operations are not implemented. The router automatically discovers peer routers through the router network and makes their management addresses available through the standard `GET-MGMT-NODES` operation.
+
+.Additional resources
+
+* link:https://www.oasis-open.org/committees/download.php/54441/AMQP%20Management%20v1.0%20WD09[AMQP Management Version 1.0 (Draft 9)]
diff --git a/docs/books/modules/user-guide/authorization.adoc b/docs/books/modules/user-guide/authorization.adoc
deleted file mode 100644
index dcc7763..0000000
--- a/docs/books/modules/user-guide/authorization.adoc
+++ /dev/null
@@ -1,586 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License
-////
-
-[id='authorizing-access-to-messaging-resources']
-= Authorizing Access to Messaging Resources
-
-You can configure _policies_ to secure messaging resources in your messaging environment. Policies ensure that only authorized users can access messaging endpoints through the router network, and that the resources on those endpoints are used in an authorized way.
-
-{RouterName} provides the following types of policies:
-
-Global policies::
-Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all messaging endpoints), and defines how the router should use vhost policies.
-
-Vhost policies::
-Connection and AMQP resource limits for a router ingress port (called an AMQP virtual host, or vhost). A vhost policy defines what a client using a particular connection can access on any messaging endpoint in the router network.
-
-The resource limits defined in global and vhost policies are applied to user connections only. The limits do not affect inter-router connections or router connections that are outbound to waypoints.
-
-Access to an AMQP resource allowed by policy for a given user connection to a given vhost is granted across the entire router network. Access restrictions are applied only at the router port to which a client is connected and only to resource requests originated by the client.
-
-== How {RouterName} Enforces Connection and Resource Limits
-
-{RouterName} uses policies to determine whether to permit a connection, and if it is permitted, to apply the appropriate resource limits.
-
-When a client creates a connection to the router, the router first determines whether to allow or deny the connection. This decision is based on the following criteria:
-
-* Whether the connection will exceed the router’s global connection limit (defined in the global policy)
-
-* Whether the connection will exceed the vhost’s connection limits (defined in the vhost policy that matches the host to which the connection is directed)
-
-If the connection is allowed, the router assigns the user (the authenticated user name from the connection) to a user group, and enforces the user group’s resource limits for the lifetime of the connection.
-
-== Setting Global Connection Limits
-
-You can set the incoming connection limit for the router. This limit defines the total number of concurrent client connections that can be open for this router.
-
-.Procedure
-
-* In the router configuration file, add a `policy` section and set the `maxConnections`.
-+
---
-[options="nowrap",subs="+quotes"]
-----
-policy {
- maxConnections: 10000
-}
-----
-`maxConnections`::
-This limit is always enforced, even if no other policy settings have been defined. The limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. The default (and the maximum) value is `65535`.
---
-
-== Setting Connection and Resource Limits for Messaging Endpoints
-
-You can define the connection limit and AMQP resource limits for a messaging endpoint by configuring a _vhost policy_. Vhost policies define what resources clients are permitted to access on a messaging endpoint over a particular connection.
-
-[NOTE]
-====
-A vhost is typically the name of the host to which the client connection is directed. For example, if a client application opens a connection to the `amqp://mybroker.example.com:5672/queue01` URL, the vhost would be `mybroker.example.com`.
-====
-
-You can create vhost policies using either of the following methods:
-
-* xref:configuring-vhost-policies-router[Configure vhost policies directly in the router configuration file]
-* xref:configuring-vhost-policies-json[Configure vhost policies as JSON files]
-
-[id='enabling-vhost-policies']
-=== Enabling Vhost Policies
-
-You must enable the router to use vhost policies before you can create the policies.
-
-.Procedure
-
-* In the router configuration file, add a `policy` section if one does not exist, and enable vhost policies for the router.
-+
---
-[options="nowrap",subs="+quotes"]
-----
-policy {
- ...
- enableVhostPolicy: true
- enableVhostNamePatterns: true | false
- defaultVhost: $default
-}
-----
-`enableVhostPolicy`::
-Enables the router to enforce the connection denials and resource limits defined in the configured vhost policies. The default is `false`, which means that the router will not enforce any vhost policies.
-
-`enableVhostNamePatterns`::
-Enables pattern matching for vhost hostnames. If set to `true`, you can use wildcards to specify a range of hostnames for a vhost. If set to `false`, vhost hostnames are treated as literal strings. This means that you must specify the exact hostname for each vhost. The default is `false`.
-
-`defaultVhost`::
-The name of the default vhost policy, which is applied to any connection for which a vhost policy has not been configured. The default is `$default`. If `defaultVhost` is not defined, then default vhost processing is disabled.
---
-
-[id='configuring-vhost-policies-router']
-=== Configuring Vhost Policies in the Router Configuration File
-
-You can configure vhost policies in the router configuration file by configuring `vhost` entities. However, if multiple routers in your router network should be configured with the same vhost configuration, you will need to add the vhost configuration to each router’s configuration file.
-
-.Prerequisites
-
-Vhost policies must be enabled for the router. For more information, see xref:enabling-vhost-policies[].
-
-.Procedure
-
-. Add a `vhost` section and define the connection limits for the messaging endpoint.
-+
---
-The connection limits apply to all users that are connected to the vhost. These limits control the number of users that can be connected simultaneously to the vhost.
-
-[options="nowrap",subs="+quotes"]
-----
-vhost {
- hostname: example.com
- maxConnections: 10000
- maxConnectionsPerUser: 100
- maxConnectionsPerHost: 100
- allowUnknownUser: true
- ...
-}
-----
-`hostname`::
-The literal hostname of the vhost (the messaging endpoint) or a pattern that matches the vhost hostname. This vhost policy will be applied to any client connection that is directed to the hostname that you specify. This name must be unique; you can only have one vhost policy per hostname.
-+
-If `enableVhostNamePatterns` is set to `true`, you can use wildcards to specify a pattern that matches a range of hostnames. For more information, see xref:pattern-matching-vhost-policy-hostnames[].
-
-`maxConnections`::
-The global maximum number of concurrent client connections allowed for this vhost. The default is 65535.
-
-`maxConnectionsPerUser`::
-The maximum number of concurrent client connections allowed for any user. The default is 65535.
-
-`maxConnectionsPerHost`::
-The maximum number of concurrent client connections allowed for any remote host (the host from which the client is connecting). The default is 65535.
-
-`allowUnknownUser`::
-Whether unknown users (users who are not members of a defined user group) are allowed to connect to the vhost. Unknown users are assigned to the $default user group and receive $default settings. The default is false, which means that unknown users are not allowed.
---
-
-. In the `vhost` section, beneath the connection settings that you added, add a `groups` entity to define the resource limits.
-+
---
-You define resource limits by user group. A user group specifies the messaging resources the members of the group are allowed to access.
-
-.User Groups in a Vhost Policy
-====
-This example shows three user groups: admin, developers, and $default:
-
-[options="nowrap",subs="+quotes"]
-----
-vhost {
- ...
- groups: {
- admin: {
- users: admin1, admin2
- remoteHosts: 127.0.0.1, ::1
- sources: *
- targets: *
- }
- developers: {
- users: dev1, dev2, dev3
- remoteHosts: *
- sources: myqueue1, myqueue2
- targets: myqueue1, myqueue2
- }
- $default: {
- remoteHosts: *
- allowDynamicSource: true,
- allowAdminStatusUpdate: true,
- sources: myqueue1, myqueue2
- targets: myqueue1, myqueue2
- }
- }
-}
-----
-`users`::
-A list of authenticated users for this user group. Use commas to separate multiple users. A user may belong to only one vhost user group.
-
-`remoteHosts`::
-A list of remote hosts from which the users may connect. A host can be a hostname, IP address, or IP address range. Use commas to separate multiple hosts. To allow access from all remote hosts, specify a wildcard `*`. To deny access from all remote hosts, leave this attribute blank.
-
-`maxConnectionsPerUser`::
-The maximum number of connections that may be created by users in this user group. This value, if specified, overrides the vhost `maxConnectionsPerUser` value.
-
-`maxConnectionsPerHost`::
-The maximum number of concurrent connections that may be created by users in this user group from any of the permitted remote hosts. This value, if specified, overrides the vhost `maxConnectionsPerUser` value.
-
-`allowDynamicSource`::
-If true, connections from users in this group are permitted to attach receivers to dynamic sources. This permits creation of listners to temporary addresses or termporary queues. If false, use of dynamic sources is forbidden.
-
-`allowAdminStatusUpdate`::
-If true, connections from users in this group are permitted to modify the adminStatus of connections. This permits termination of sender or receiver connections. If false, the users of this group are prohibited from terminating any connections. Inter-router connections can never be terminated by any user under any circumstance. Defaults to true, no policy required.
-
-
-`allowWaypointLinks`::
-If true, connections from users in this group are permitted to attach links using waypoint capabilities. This allows endpoints to act as waypoints (i.e. brokers) without the need for configuring auto-links. If false, use of waypoint capabilities is forbidden.
-
-`allowDynamicLinkRoutes`::
-If true, connections from users in this group may dynamically create connection-scoped link route destinations. This allows endpoints to act as link route destinations (i.e. brokers) without the need for configuring link-routes. If false, creation of dynamic link route destintations is forbidden.
-
-`allowFallbackLinks`::
-If true, connections from users in this group are permitted to attach links using fallback-link capabilities. This allows endpoints to act as fallback destinations (and sources) for addresses that have fallback enabled. If false, use of fallback-link capabilities is forbidden.
-
-`sources` | `sourcePattern`::
-A list of AMQP source addresses from which users in this group may receive messages.
-+
-Use `sources` to specify one or more literal addresses. To specify multiple addresses, use a comma-separated list. To prevent users in this group from receiving messages from any addresses, leave this attribute blank. To allow access to an address specific to a particular user, specify the `${user}` token. For more information, see xref:methods-for-specifying-vhost-policy-source-target-addresses[].
-+
-Alternatively, you can use `sourcePattern` to match one or more addresses that correspond to a pattern. A pattern is a sequence of words delimited by either a `.` or `/` character. You can use wildcard characters to represent a word. The `*` character matches exactly one word, and the `#` character matches any sequence of zero or more words.
-+
-To specify multiple address ranges, use a comma-separated list of address patterns. For more information, see xref:router-address-pattern-matching[Router Address Pattern Matching]. To allow access to address ranges that are specific to a particular user, specify the `${user}` token. For more information, see xref:methods-for-specifying-vhost-policy-source-target-addresses[].
-
-`targets` | `targetPattern`::
-A list of AMQP target addresses from which users in this group may send messages. You can specify multiple AMQP addresses and use user name substitution and address patterns the same way as with source addresses.
-====
---
-
-. If necessary, add any advanced user group settings to the vhost user groups.
-+
-The advanced user group settings enable you to define resource limits based on the AMQP connection open, session begin, and link attach phases of the connection. For more information, see link:{qdrouterdConfManPageUrl}#_vhost[vhost^] in the `qdrouterd.conf` man page.
-
-[id='configuring-resource-limits-outgoing-connections']
-=== Configuring Resource Limits for Outgoing Connections
-
-If the router establishes an outgoing connection to an external AMQP container (such as a client or broker), you can restrict the resources that the external container can access on the router by configuring a connector vhost policy.
-
-The resource limits that are defined in a connector vhost policy are applied to links that are initiated by the external AMQP container. The connector vhost policy does not restrict links that the router creates.
-
-A connector vhost policy can only be applied to a connector with a `normal` or `route-container` role. You cannot apply connector vhost policies to connectors that have `inter-router` or `edge` roles.
-
-.Prerequisites
-
-Vhost policies are enabled for the router. For more information, see xref:enabling-vhost-policies[].
-
-.Procedure
-
-. In the router's configuration file, add a `vhost` section with a `$connector` user group.
-+
---
-[options="nowrap"]
-----
-vhost {
- hostname: my-connector-policy
- groups: {
- $connector: {
- sources: *
- targets: *
- maxSenders: 5
- maxReceivers: 10
- allowAnonymousSender: true
- allowWaypointLinks: true
- }
- }
-}
-----
-`hostname`:: A unique name to identify the connector vhost policy. This name does not represent an actual hostname; therefore, choose a name that will not conflict with an actual vhost hostname.
-`$connector`:: Identifies this vhost policy as a connector vhost policy.
---
-
-. Apply the connector vhost policy to the connector that establishes the connection to the external AMQP container.
-+
---
-The following example applies the connector vhost policy that was configured in the previous step:
-
-[options="nowrap"]
-----
-connector {
- host: 192.0.2.10
- port: 5672
- role: normal
- policyVhost: my-connector-policy
-}
-----
---
-
-[id='configuring-vhost-policies-json']
-=== Configuring Vhost Policies as JSON Files
-
-As an alternative to using the router configuration file, you can configure vhost policies in JSON files. If you have multiple routers that need to share the same vhost configuration, you can put the vhost configuration JSON files in a location accessible to each router, and then configure the routers to apply the vhost policies defined in these JSON files.
-
-.Prerequisites
-
-* Vhost policies must be enabled for the router. For more information, see xref:enabling-vhost-policies[].
-
-.Procedure
-
-. In the router configuration file, specify the directory where you want to store the vhost policy definition JSON files.
-+
---
-[options="nowrap",subs="+quotes"]
-----
-policy {
- ...
- policyDir: __DIRECTORY_PATH__
-}
-----
-`policyDir`::
-The absolute path to the directory that holds vhost policy definition files in JSON format. The router processes all of the vhost policies in each JSON file that is in this directory.
---
-
-. In the vhost policy definition directory, create a JSON file for each vhost policy.
-+
---
-.Vhost Policy Definition JSON File
-====
-[source,json,options="nowrap"]
-----
-[
- ["vhost", {
- "hostname": "example.com",
- "maxConnections": 10000,
- "maxConnectionsPerUser": 100,
- "maxConnectionsPerHost": 100,
- "allowUnknownUser": true,
- "groups": {
- "admin": {
- "users": ["admin1", "admin2"],
- "remoteHosts": ["127.0.0.1", "::1"],
- "sources": "*",
- "targets": "*"
- },
- "developers": {
- "users": ["dev1", "dev2", "dev3"],
- "remoteHosts": "*",
- "sources": ["myqueue1", "myqueue2"],
- "targets": ["myqueue1", "myqueue2"]
- },
- "$default": {
- "remoteHosts": "*",
- "allowDynamicSource": true,
- "sources": ["myqueue1", "myqueue2"],
- "targets": ["myqueue1", "myqueue2"]
- }
- }
- }]
-]
-----
-
-For more information about these attributes, see xref:configuring-vhost-policies-router[].
-====
---
-
-[id='pattern-matching-vhost-policy-hostnames']
-=== Pattern Matching for Vhost Policy Hostnames
-
-In a vhost policy, vhost hostnames can be either literal hostnames or patterns that cover a range of hostnames.
-
-A hostname pattern is a sequence of words with one or more of the following wildcard characters:
-
-* `*` represents exactly one word
-* `#` represents zero or more words
-
-The following table shows some examples of hostname patterns:
-
-[options="header"]
-|===
-| This pattern... | Matches... | But not...
-
-a| `*.example.com`
-a| `www.example.com`
-a| `example.com`
-`srv2.www.example.com`
-
-a| `#.example.com`
-a| `example.com`
-`www.example.com`
-`a.b.c.d.example.com`
-a| `myhost.com`
-
-a| `www.*.test.example.com`
-a| `www.a.test.example.com`
-a| `www.test.example.com`
-`www.a.b.c.test.example.com`
-
-a| `www.#.test.example.com`
-a| `www.test.example.com`
-`www.a.test.example.com`
-`www.a.b.c.test.example.com`
-a| `test.example.com`
-|===
-
-Vhost hostname pattern matching applies the following precedence rules:
-
-[options="header"]
-|===
-| Policy pattern | Precedence
-| Exact match | High
-| * | Medium
-| # | Low
-|===
-
-[NOTE]
-====
-{RouterName} does not permit you to create vhost hostname patterns that conflict with existing patterns. This includes patterns that can be reduced to be the same as an existing pattern. For example, you would not be able to create the `\#.#.\#.#.com` pattern if `#.com` already exists.
-====
-
-[id='methods-for-specifying-vhost-policy-source-target-addresses']
-=== Methods for Specifying Vhost Policy Source and Target Addresses
-
-If you want to allow or deny access to multiple addresses on a vhost, there are several methods you can use to match multiple addresses without having to specify each address individually.
-
-The following table describes the methods a vhost policy can use to specify multiple source and target addresses:
-
-[cols="33,67",options="header"]
-|===
-| To... | Do this...
-
-| Allow all users in the user group to access all source or target addresses
-a| Use a `*` wildcard character.
-
-.Receive from Any Address
-====
-[source,options="nowrap"]
-----
-sources: *
-----
-====
-
-| Prevent all users in the user group from accessing all source or target addresses
-a| Do not specify a value.
-
-.Prohibit Message Transfers to All Addresses
-====
-[source,options="nowrap"]
-----
-targets:
-----
-====
-
-| Allow access to some resources specific to each user
-a| Use the `${user}` username substitution token. You can use this token with `source`, `target`, `sourcePattern`, and `targetPattern`.
-
-[NOTE]
-====
-You can only specify the `${user}` token once in an AMQP address name or pattern. If there are multiple tokens in an address, only the leftmost token will be substituted.
-====
-
-.Receive from a User-Specific Address
-====
-This definition allows the users in the user group to receive messages from any address that meets any of the following rules:
-
-* Starts with the prefix `tmp_` and ends with the user name
-* Starts with the prefix `temp` followed by any additional characters
-* Starts with the user name, is followed by `-home-`, and ends with any additional characters
-[source,options="nowrap"]
-----
-sources: tmp_${user}, temp*, ${user}-home-*
-----
-====
-
-.User-Specific Address Patterns
-====
-This definition allows the users in the user group to receive messages from any address that meets any of the following rules:
-
-* Starts with the prefix `tmp` and ends with the user name
-* Starts with the prefix `temp` followed by zero or more additional characters
-* Starts with the user name, is followed by `home`, and ends with one or more additional characters
-[source,options="nowrap"]
-----
-sourcePattern: tmp.${user}, temp/#, ${user}.home/*
-----
-====
-
-[NOTE]
-====
-In an address pattern (`sourcePattern` or `targetPattern`), the username substitution token must be either the first or last token in the pattern. The token must also be alone within its delimited field, which means that it cannot be concatenated with literal text prefixes or suffixes.
-====
-
-|===
-
-=== Vhost Policy Examples
-
-These examples demonstrate how to use vhost policies to authorize access to messaging resources.
-
-.Defining Basic Resource Limits for a Messaging Endpoint
-====
-In this example, a vhost policy defines resource limits for clients connecting to the `example.com` host.
-
-[source,json,options="nowrap"]
-----
-[
- ["vhost", {
- "hostname": "example.com", // <1>
- "maxConnectionsPerUser": 10, // <2>
- "allowUnknownUser": true, // <3>
- "groups": {
- "admin": {
- "users": ["admin1", "admin2"], // <4>
- "remoteHosts": ["127.0.0.1", "::1"], // <5>
- "sources": "*", // <6>
- "targets": "*" // <7>
- },
- "$default": {
- "remoteHosts": "*", // <8>
- "sources": ["news*", "sports*" "chat*"], // <9>
- "targets": "chat*" // <10>
- }
- }
- }]
-]
-----
-
-<1> The rules defined in this vhost policy will be applied to any user connecting to `example.com`.
-
-<2> Each user can open up to 10 connections to the vhost.
-
-<3> Any user can connect to this vhost. Users that are not part of the `admin` group are assigned to the `$default` group.
-
-<4> If the `admin1` or `admin2` user connects to the vhost, they are assigned to the `admin` user group.
-
-<5> Users in the `admin` user group must connect from localhost. If the admin user attempts to connect from any other host, the connection will be denied.
-
-<6> Users in the admin user group can receive from any address.
-
-<7> Users in the admin user group can send to any address.
-
-<8> Any non-admin user is permitted to connect from any host.
-
-<9> Non-admin users are permitted to receive messages from any addresses that start with the `news`, `sports`, or `chat` prefixes.
-
-<10> Non-admin users are permitted to send messages to any addresses that start with the `chat` prefix.
-====
-
-.Limiting Memory Consumption
-====
-By using the advanced vhost policy attributes, you can control how much system buffer memory a user connection can potentially consume.
-
-In this example, a stock trading site provides services for stock traders. However, the site must also accept high-capacity, automated data feeds from stock exchanges. To prevent trading activity from consuming memory needed for the feeds, a larger amount of system buffer memory is allotted to the feeds than to the traders.
-
-This example uses the `maxSessions` and `maxSessionWindow` attributes to set the buffer memory consumption limits for each AMQP session. These settings are passed directly to the AMQP connection and session negotiations, and do not require any processing cycles on the router.
-
-This example does not show the vhost policy settings that are unrelated to buffer allocation.
-
-[source,json,options="nowrap"]
-----
-[
- ["vhost", {
- "hostname": "traders.com", // <1>
- "groups": {
- "traders": {
- "users": ["trader1", "trader2"], // <2>
- "maxFrameSize": 10000,
- "maxSessionWindow": 5000000, // <3>
- "maxSessions": 1 // <4>
- },
- "feeds": {
- "users": ["nyse-feed", "nasdaq-feed"], // <5>
- "maxFrameSize": 60000,
- "maxSessionWindow": 1200000000, // <6>
- "maxSessions": 3 // <7>
- }
- }
- }]
-]
-----
-
-<1> The rules defined in this vhost policy will be applied to any user connecting to `traders.com`.
-
-<2> The `traders` group includes `trader1`, `trader2`, and any other user defined in the list.
-
-<3> At most, 5,000,000 bytes of data can be in flight on each session.
-
-<4> Only one session per connection is allowed.
-
-<5> The `feeds` group includes two users.
-
-<6> At most, 1,200,000,000 bytes of data can be in flight on each session.
-
-<7> Up to three sessions per connection are allowed.
-====
diff --git a/docs/books/modules/user-guide/changing-router-configuration.adoc b/docs/books/modules/user-guide/changing-router-configuration.adoc
new file mode 100644
index 0000000..423328d
--- /dev/null
+++ b/docs/books/modules/user-guide/changing-router-configuration.adoc
@@ -0,0 +1,49 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// managing-router.adoc
+
+[id='changing-router-configuration-{context}']
+= Changing a router's configuration
+
+You can make a permanent change to a router’s configuration by editing the router’s configuration file directly. You must restart the router for the changes to take effect, but the changes will be saved even if the router is stopped.
+
+.Procedure
+
+. Do one of the following:
++
+--
+** Edit the default configuration file (`{RouterConfigFile}`).
+** Create a new configuration file.
+--
+
+. Start (or restart) the router.
++
+--
+For more information, see xref:starting-router-{context}[].
+
+If you created a new configuration file, you must specify the path using the `--conf` parameter. For example, the following command starts the router with a non-default configuration file:
+
+[options="nowrap",subs="+quotes"]
+----
+$ qdrouterd -d --conf /etc/qpid-dispatch/new-configuration-file.conf
+----
+--
diff --git a/docs/books/modules/user-guide/commands-monitoring-router-network.adoc b/docs/books/modules/user-guide/commands-monitoring-router-network.adoc
new file mode 100644
index 0000000..0187a77
--- /dev/null
+++ b/docs/books/modules/user-guide/commands-monitoring-router-network.adoc
@@ -0,0 +1,124 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// monitoring-using-qdstat.adoc
+
+[id='commands-monitoring-router-network-{context}']
+= Commands for monitoring the router network
+
+You can use `qdstat` to view the status of routers on your router network. For example, you can view information about the attached links and configured addresses, available connections, and nodes in the router network.
+
+[cols="50,50"]
+|===
+| To... | Use this command...
+
+| Create a state dump containing all statistics for all routers
+
+A state dump shows the current operational state of the router network.
+a|
+[options="nowrap"]
+----
+$ qdstat --all-routers --all-entities
+----
+
+If you run this command on an interior router, it displays the statistics for all interior routers. If you run the command on an edge router, it displays the statistics for only that edge router.
+
+| Create a state dump containing a single statistic for all routers
+a|
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -l\|-a\|-c\|--autolinks\|--linkroutes\|-g\|-m --all-routers
+----
+
+If you run this command on an interior router, it displays the statistic for all interior routers. If you run the command on an edge router, it displays the statistic for only that edge router.
+
+| Create a state dump containing all statistics for a single router
+a|
+[options="nowrap"]
+----
+$ qdstat --all-entities
+----
+
+This command shows the statistics for the local router only.
+
+| View general statistics for a router
+a|
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -g [all-routers\|__<connection-options>__]
+----
+
+| View a list of connections to a router
+a|
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -c [all-routers\|__<connection-options>__]
+----
+
+| View the AMQP links attached to a router
+
+You can view a list of AMQP links attached to the router from clients (sender/receiver), from or to other routers into the network, to other containers (for example, brokers), and from the tool itself.
+a|
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -l [all-routers\|__<connection-options>__]
+----
+
+| View known routers on the router network
+a|
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -n [all-routers\|__<connection-options>__]
+----
+
+| View the addresses known to a router
+a|
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -a [all-routers\|__<connection-options>__]
+----
+
+| View a router's autolinks
+a|
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat --autolinks [all-routers\|__<connection-options>__]
+----
+
+| View the status of a router's link routes
+a|
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat --linkroutes [all-routers\|__<connection-options>__]
+----
+
+| View a router's memory consumption
+a|
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat -m [all-routers\|__<connection-options>__]
+----
+
+|===
+
+.Additional resources
+
+* For more information about the fields displayed by each `qdstat` command, see the {qdstatManPageLink}.
diff --git a/docs/books/modules/user-guide/configuring-address-semantics.adoc b/docs/books/modules/user-guide/configuring-address-semantics.adoc
new file mode 100644
index 0000000..6614903
--- /dev/null
+++ b/docs/books/modules/user-guide/configuring-address-semantics.adoc
@@ -0,0 +1,65 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// configuring-address-space-message-routing.adoc
+
+[id='configuring-address-semantics-{context}']
+= Configuring address semantics
+
+You can route messages between clients without using a broker. In a brokerless scenario (sometimes called _direct-routed messaging_), {RouterName} routes messages between clients directly.
+
+To route messages between clients, you configure an address with a routing distribution pattern. When a router receives a message with this address, the message is routed to its destination or destinations based on the address's routing distribution pattern.
+
+.Procedure
+
+. In the `{RouterConfigFile}` configuration file, add an `address` section.
++
+--
+[options="nowrap",subs="+quotes"]
+----
+address {
+ prefix: my_address
+ distribution: multicast
+ ...
+}
+----
+
+`prefix` | `pattern`::
+The address or group of addresses to which the address settings should be applied. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
++
+include::{FragmentDir}/fragment-prefix-matching-definition.adoc[]
++
+include::{FragmentDir}/fragment-pattern-matching-definition.adoc[]
+
+`distribution`:: The message distribution pattern. The default is `balanced`, but you can specify any of the following options:
++
+* `balanced` - Messages sent to the address will be routed to one of the receivers, and the routing network will attempt to balance the traffic load based on the rate of settlement.
+* `closest` - Messages sent to the address are sent on the shortest path to reach the destination. It means that if there are multiple receivers for the same address, only the closest one will receive the message.
+* `multicast` - Messages are sent to all receivers that are attached to the address in a _publish/subscribe_ model.
++
+For more information about message distribution patterns, see xref:routing-patterns-message-routing-{context}[].
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_address[address] in the `qdrouterd.conf` man page.
+--
+
+. Add the same `address` section to any other routers that need to use the address.
++
+The `address` that you added to this router configuration file only controls how this router distributes messages sent to the address. If you have additional routers in your router network that should distribute messages for this address, then you must add the same `address` section to each of their configuration files.
diff --git a/docs/books/modules/user-guide/configuring-addresses-prioritized-message-delivery.adoc b/docs/books/modules/user-guide/configuring-addresses-prioritized-message-delivery.adoc
new file mode 100644
index 0000000..73125d4
--- /dev/null
+++ b/docs/books/modules/user-guide/configuring-addresses-prioritized-message-delivery.adoc
@@ -0,0 +1,56 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// configuring-address-space-message-routing.adoc
+
+[id='configuring-addresses-prioritized-message-delivery-{context}']
+= Configuring addresses for prioritized message delivery
+
+You can set the priority level of an address to control how {RouterName} processes messages sent to that address. Within the scope of a connection, {RouterName} attempts to process messages based on their priority. For a connection with a large volume of messages in flight, this lowers the latency for higher-priority messages.
+
+Assigning a high priority level to an address does not guarantee that messages sent to the address will be delivered before messages sent to lower-priority addresses. However, higher-priority messages will travel more quickly through the router network than they otherwise would.
+
+[NOTE]
+====
+You can also control the priority level of individual messages by setting the priority level in the message header. However, the address priority takes precedence: if you send a prioritized message to an address with a different priority level, the router will use the address priority level.
+====
+
+.Procedure
+
+* In the `{RouterConfigFile}` configuration file, add or edit an address and assign a priority level.
++
+--
+This example adds an address with the highest priority level. The router will attempt to deliver messages sent to this address before messages with lower priority levels.
+
+[options="nowrap",subs="+quotes"]
+----
+address {
+ prefix: my-high-priority-address
+ priority: 9
+ ...
+}
+----
+`priority`:: The priority level to assign to all messages sent to this address. The range of valid priority levels is 0-9, in which the higher the number, the higher the priority. The default is 4.
+--
+
+.Additional resources
+
+* For more information about setting the priority level in a message, see the {AmqpSpecLink}.
diff --git a/docs/books/modules/user-guide/configuring-default-logging.adoc b/docs/books/modules/user-guide/configuring-default-logging.adoc
new file mode 100644
index 0000000..f2086e6
--- /dev/null
+++ b/docs/books/modules/user-guide/configuring-default-logging.adoc
@@ -0,0 +1,81 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// configuring-logging.adoc
+
+[id='configuring-default-logging-{context}']
+= Configuring default logging
+
+You can specify the types of events that should be logged, the format of the log entries, and where those entries should be sent.
+
+.Procedure
+
+. In the `{RouterConfigFile}` configuration file, add a `log` section to set the default logging properties:
++
+--
+This example configures all logging modules to log events starting at the `info` level:
+
+[options="nowrap",subs="+quotes"]
+----
+log {
+ module: DEFAULT
+ enable: info+
+ includeTimestamp: yes
+}
+----
+
+`module`:: Specify `DEFAULT`.
+
+`enable`:: The logging level. You can specify any of the following levels (from lowest to highest):
++
+* `trace` - provides the most information, but significantly affects system performance
+* `debug` - useful for debugging, but affects system performance
+* `info` - provides general information without affecting system performance
+* `notice` - provides general information, but is less verbose than `info`
+* `warning` - provides information about issues you should be aware of, but which are not errors
+* `error` - error conditions that you should address
+* `critical` - critical system issues that you must address immediately
+
++
+To specify multiple levels, use a comma-separated list. You can also use `+` to specify a level and all levels above it. For example, `trace,debug,warning+` enables trace, debug, warning, error, and critical levels. For default logging, you should typically use the `info+` or `notice+` level. These levels will provide general information, warnings, and errors for all modules without affecting the performance of {RouterName}.
+
+`includeTimestamp`:: Set this to `yes` to include the timestamp in all logs.
+
+For information about additional log attributes, see link:{qdrouterdConfManPageUrl}#_log[log] in the `qdrouterd.conf` man page.
+--
+
+. If you want to configure non-default logging for any of the logging modules, add an additional `log` section for each module that should not follow the default.
++
+--
+This example configures the `ROUTER` logging module to log `debug` events:
+[options="nowrap",subs="+quotes"]
+----
+log {
+ module: ROUTER
+ enable: debug
+ includeTimestamp: yes
+}
+----
+--
+
+.Additional resources
+
+* For more information about viewing and using logs, see xref:troubleshooting-{context}[].
diff --git a/docs/books/modules/user-guide/creating-link-route.adoc b/docs/books/modules/user-guide/creating-link-route.adoc
new file mode 100644
index 0000000..3b925cf
--- /dev/null
+++ b/docs/books/modules/user-guide/creating-link-route.adoc
@@ -0,0 +1,113 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// configuring-link-routing.adoc
+
+[id='creating-link-route-{context}']
+= Creating a link route
+
+Link routes establish a link between a sender and a receiver that travels through a router. You can configure inward and outward link routes to enable the router to receive link-attaches from clients and to send them to a particular destination.
+
+With link routing, client traffic is handled on the broker, not the router. Clients have a direct link through the router to a broker's queue. Therefore, each client is a separate producer or consumer.
+
+[NOTE]
+====
+If the connection to the broker fails, the routed links are detached, and the router will attempt to reconnect to the broker (or its backup). Once the connection is reestablished, the link route to the broker will become reachable again.
+
+From the client's perspective, the client will see the detached links (that is, the senders or receivers), but not the failed connection. Therefore, if you want the client to reattach dropped links in the event of a broker connection failure, you must configure this functionality on the client. Alternatively, you can use message routing with autolinks instead of link routing. For more information, see xref:routing-messages-through-broker-queues-{context}[].
+====
+
+.Procedure
+
+. Add an outgoing connection to the broker if one does not exist.
++
+If the queue is sharded across multiple brokers, you must add a connection for each broker. For more information, see xref:connecting-to-external-amqp-containers-{context}[].
+
+. If you want clients to send local transactions to the broker, create a link route for the transaction coordinator:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+linkRoute {
+ prefix: $coordinator <1>
+ connection: my_broker
+ direction: in
+}
+----
+<1> The `$coordinator` prefix designates this link route as a transaction coordinator. When the client opens a transacted session, the requests to start and end the transaction are propagated along this link route to the broker.
+
+{RouterName} does not support routing transactions to multiple brokers. If you have multiple brokers in your environment, choose a single broker and route all transactions to it.
+--
+
+. If you want clients to send messages on this link route, create an incoming link route:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+linkRoute {
+ prefix: my_queue
+ connection: my_broker
+ direction: in
+ ...
+}
+----
+
+`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue that should be the destination for routed link-attaches. All messages that match this prefix or pattern will be distributed along the link route. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
++
+include::{FragmentDir}/fragment-prefix-matching-definition.adoc[]
++
+include::{FragmentDir}/fragment-pattern-matching-definition.adoc[]
+
+`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
++
+If multiple brokers are connected to the router through this connection, requests for addresses matching the link route's prefix or pattern are balanced across the brokers. Alternatively, if you want to specify a particular broker, use `containerID` and add the broker's container ID.
+
+`direction`:: Set this attribute to `in` to specify that clients can send messages into the router network on this link route.
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_linkroute[linkRoute] in the `qdrouterd.conf` man page.
+--
+
+. If you want clients to receive messages on this link route, create an outgoing link route:
++
+--
+[options="nowrap",subs="+quotes"]
+----
+linkRoute {
+ prefix: my_queue
+ connection: my_broker
+ direction: out
+ ...
+}
+----
+
+`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue from which you want to receive routed link-attaches. All messages that match this prefix or pattern will be distributed along the link route. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
++
+include::{FragmentDir}/fragment-prefix-matching-definition.adoc[]
++
+include::{FragmentDir}/fragment-pattern-matching-definition.adoc[]
+
+`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
++
+If multiple brokers are connected to the router through this connection, requests for addresses matching the link route's prefix or pattern are balanced across the brokers. Alternatively, if you want to specify a particular broker, use `containerID` and add the broker's container ID.
+`direction`:: Set this attribute to `out` to specify that this link route is for receivers.
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_linkroute[linkRoute] in the `qdrouterd.conf` man page.
+--
diff --git a/docs/books/modules/user-guide/creating-vhost-policies-json.adoc b/docs/books/modules/user-guide/creating-vhost-policies-json.adoc
new file mode 100644
index 0000000..977b893
--- /dev/null
+++ b/docs/books/modules/user-guide/creating-vhost-policies-json.adoc
@@ -0,0 +1,89 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// setting-connection-resource-limits-messaging-endpoints.adoc
+
+[id='creating-vhost-policies-json-{context}']
+= Creating vhost policies as JSON files
+
+As an alternative to using the router configuration file, you can configure vhost policies in JSON files. If you have multiple routers that need to share the same vhost configuration, you can put the vhost configuration JSON files in a location accessible to each router, and then configure the routers to apply the vhost policies defined in these JSON files.
+
+.Prerequisites
+
+* Vhost policies must be enabled for the router. For more information, see xref:enabling-vhost-policies-{context}[].
+
+.Procedure
+
+. In the `{RouterConfigFile}` configuration file, specify the directory where you want to store the vhost policy definition JSON files.
++
+--
+[options="nowrap",subs="+quotes"]
+----
+policy {
+ ...
+ policyDir: /etc/qpid-dispatch-policies
+}
+----
+`policyDir`::
+The absolute path to the directory that holds vhost policy definition files in JSON format. The router processes all of the vhost policies in each JSON file that is in this directory.
+--
+
+. In the vhost policy definition directory, create a JSON file for each vhost policy.
++
+--
+.Vhost Policy Definition JSON File
+====
+[source,json,options="nowrap"]
+----
+[
+ ["vhost", {
+ "hostname": "example.com",
+ "maxConnections": 10000,
+ "maxConnectionsPerUser": 100,
+ "maxConnectionsPerHost": 100,
+ "allowUnknownUser": true,
+ "groups": {
+ "admin": {
+ "users": ["admin1", "admin2"],
+ "remoteHosts": ["127.0.0.1", "::1"],
+ "sources": "*",
+ "targets": "*"
+ },
+ "developers": {
+ "users": ["dev1", "dev2", "dev3"],
+ "remoteHosts": "*",
+ "sources": ["myqueue1", "myqueue2"],
+ "targets": ["myqueue1", "myqueue2"]
+ },
+ "$default": {
+ "remoteHosts": "*",
+ "allowDynamicSource": true,
+ "sources": ["myqueue1", "myqueue2"],
+ "targets": ["myqueue1", "myqueue2"]
+ }
+ }
+ }]
+]
+----
+
+For more information about these attributes, see xref:creating-vhost-policies-{context}[].
+====
+--
diff --git a/docs/books/modules/user-guide/creating-vhost-policies.adoc b/docs/books/modules/user-guide/creating-vhost-policies.adoc
new file mode 100644
index 0000000..7f61ef9
--- /dev/null
+++ b/docs/books/modules/user-guide/creating-vhost-policies.adoc
@@ -0,0 +1,145 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// setting-connection-resource-limits-messaging-endpoints.adoc
+
+[id='creating-vhost-policies-{context}']
+= Creating vhost policies
+
+A vhost policy defines the connection limits and resource limits for users connecting to the router from a remote host. You must create one vhost policy for each remote host.
+
+.Prerequisites
+
+Vhost policies must be enabled for the router. For more information, see xref:enabling-vhost-policies-{context}[].
+
+.Procedure
+
+. Add a `vhost` section and define the connection limits for the messaging endpoint.
++
+--
+The connection limits apply to all users that are connected to the vhost. These limits control the number of users that can be connected simultaneously to the vhost.
+
+[options="nowrap",subs="+quotes"]
+----
+vhost {
+ hostname: example.com
+ maxConnections: 10000
+ maxConnectionsPerUser: 100
+ maxConnectionsPerHost: 100
+ allowUnknownUser: true
+ ...
+}
+----
+`hostname`::
+The literal hostname of the vhost (the messaging endpoint) or a pattern that matches the vhost hostname. This vhost policy will be applied to any client connection that is directed to the hostname that you specify. This name must be unique; you can only have one vhost policy per hostname.
++
+If `enableVhostNamePatterns` is set to `true`, you can use wildcards to specify a pattern that matches a range of hostnames. For more information, see xref:vhost-policy-hostname-pattern-matching-rules-{context}[].
+
+`maxConnections`::
+The global maximum number of concurrent client connections allowed for this vhost. The default is 65535.
+
+`maxConnectionsPerUser`::
+The maximum number of concurrent client connections allowed for any user. The default is 65535.
+
+`maxConnectionsPerHost`::
+The maximum number of concurrent client connections allowed for any remote host (the host from which the client is connecting). The default is 65535.
+
+`allowUnknownUser`::
+Whether unknown users (users who are not members of a defined user group) are allowed to connect to the vhost. Unknown users are assigned to the `$default` user group and receive `$default` settings. The default is `false`, which means that unknown users are not allowed.
+--
+
+. In the `vhost` section, beneath the connection settings that you added, add a `groups` entity to define the resource limits.
++
+--
+You define resource limits by user group. A user group specifies the messaging resources the members of the group are allowed to access.
+
+This example shows three user groups: admin, developers, and $default:
+
+[options="nowrap",subs="+quotes"]
+----
+vhost {
+ ...
+ groups: {
+ admin: {
+ users: admin1, admin2
+ remoteHosts: 127.0.0.1, ::1
+ sources: *
+ targets: *
+ }
+ developers: {
+ users: dev1, dev2, dev3
+ remoteHosts: *
+ sources: myqueue1, myqueue2
+ targets: myqueue1, myqueue2
+ }
+ $default: {
+ remoteHosts: *
+ allowDynamicSource: true,
+ allowAdminStatusUpdate: true,
+ sources: myqueue1, myqueue2
+ targets: myqueue1, myqueue2
+ }
+ }
+}
+----
+`users`::
+A list of authenticated users for this user group. Use commas to separate multiple users. A user may belong to only one vhost user group.
+
+`remoteHosts`::
+A list of remote hosts from which the users may connect. A host can be a hostname, IP address, or IP address range. Use commas to separate multiple hosts. To allow access from all remote hosts, specify a wildcard `*`. To deny access from all remote hosts, leave this attribute blank.
+
+`maxConnectionsPerUser`::
+The maximum number of connections that may be created by users in this user group. This value, if specified, overrides the vhost `maxConnectionsPerUser` value.
+
+`maxConnectionsPerHost`::
+The maximum number of concurrent connections that may be created by users in this user group from any of the permitted remote hosts. This value, if specified, overrides the vhost `maxConnectionsPerUser` value.
+
+`allowDynamicSource`::
+If `true`, connections from users in this group are permitted to attach receivers to dynamic sources. This permits creation of listeners to temporary addresses or temporary queues. If `false`, use of dynamic sources is not permitted.
+
+`allowAdminStatusUpdate`::
+If `true`, connections from users in this group are permitted to modify the `adminStatus` of connections. This permits termination of sender or receiver connections. If `false`, the users of this group are prohibited from terminating any connections. Inter-router connections can never be terminated by any usee. The default is `true`, even if the policy is not configured.
+
+`allowWaypointLinks`::
+If `true`, connections from users in this group are permitted to attach links using waypoint capabilities. This allows endpoints to act as waypoints (that is, brokers) without the need for configuring auto-links. If `false`, use of waypoint capabilities is not permitted.
+
+`allowDynamicLinkRoutes`::
+If `true`, connections from users in this group may dynamically create connection-scoped link route destinations. This allows endpoints to act as link route destinations (that is, brokers) without the need for configuring link routes. If `false`, creation of dynamic link route destinations is not permitted.
+
+`allowFallbackLinks`::
+If `true`, connections from users in this group are permitted to attach links using fallback-link capabilities. This allows endpoints to act as fallback destinations (and sources) for addresses that have fallback enabled. If `false`, use of fallback-link capabilities is not permitted.
+
+`sources` | `sourcePattern`::
+A list of AMQP source addresses from which users in this group may receive messages.
++
+Use `sources` to specify one or more literal addresses. To specify multiple addresses, use a comma-separated list. To prevent users in this group from receiving messages from any addresses, leave this attribute blank. To allow access to an address specific to a particular user, specify the `${user}` token. For more information, see xref:methods-specifying-vhost-policy-source-target-addresses-{context}[].
++
+Alternatively, you can use `sourcePattern` to match one or more addresses that correspond to a pattern. A pattern is a sequence of words delimited by either a `.` or `/` character. You can use wildcard characters to represent a word. The `*` character matches exactly one word, and the `#` character matches any sequence of zero or more words.
++
+To specify multiple address ranges, use a comma-separated list of address patterns. For more information, see xref:address-pattern-matching-{context}[]. To allow access to address ranges that are specific to a particular user, specify the `${user}` token. For more information, see xref:methods-specifying-vhost-policy-source-target-addresses-{context}[].
+
+`targets` | `targetPattern`::
+A list of AMQP target addresses from which users in this group may send messages. You can specify multiple AMQP addresses and use user name substitution and address patterns the same way as with source addresses.
+--
+
+. If necessary, add any advanced user group settings to the vhost user groups.
++
+The advanced user group settings enable you to define resource limits based on the AMQP connection open, session begin, and link attach phases of the connection. For more information, see link:{qdrouterdConfManPageUrl}#_vhost[vhost^] in the `qdrouterd.conf` man page.
diff --git a/docs/books/modules/user-guide/cyrus-sasl.adoc b/docs/books/modules/user-guide/cyrus-sasl.adoc
deleted file mode 100644
index 3618ffc..0000000
--- a/docs/books/modules/user-guide/cyrus-sasl.adoc
+++ /dev/null
@@ -1,90 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License
-////
-
-[id='cyrus-sasl']
-= Using Cyrus SASL to Provide Authentication
-
-// Just doing some basic editing for now; for future releases, this content will need some more work. Also need to determine if it should be moved from an appendix to the section that deals with setting up SASL.
-
-{RouterName} uses the Cyrus SASL library for SASL authentication. Therefore, if you want to use SASL, you must set up the Cyrus SASL database and configure it.
-
-[id='generating-sasl-database']
-== Generating a SASL Database
-
-To generate a SASL database to store credentials, enter the following command:
-
-[options="nowrap",subs="+quotes"]
-----
-$ sudo saslpasswd2 -c -f _SASL_DATABASE_NAME_.sasldb -u _DOMAIN_NAME_ _USER_NAME_
-----
-
-This command creates or updates the specified SASL database, and adds the specified user name to it. The command also prompts you for the user name's password.
-
-// What is the goal here - to add user credentials to the database? If so, do you need to run this command for every user that you want to add? When it says that the command prompts for the password, does that mean you use the prompt to set the user's password?
-
-The full user name is the user name you entered plus the domain name (`__USER_NAME__`@`__DOMAIN_NAME__`). Providing a domain name is not required when you add a user to the database, but if you do not provide one, a default domain will be added automatically (the hostname of the machine on which the tool is running). For example, in the command above, the full user name would be `user1@domain.com`.
-
-== Viewing Users in a SASL Database
-
-To view the user names stored in the SASL database:
-
-[options="nowrap",subs="+quotes"]
-----
-$ sudo sasldblistusers2 -f qdrouterd.sasldb
-user2@domain.com: __PASSWORD__
-user1@domain.com: __PASSWORD__
-----
-
-[id='configuring-sasl-database']
-== Configuring a SASL Database
-
-To use the SASL database to provide authentication in {RouterName}:
-
-. Open the `/etc/sasl2/qdrouterd.conf` configuration file.
-
-. Set the following attributes:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-pwcheck_method: auxprop
-auxprop_plugin: sasldb
-sasldb_path: __SASL_DATABASE_NAME__
-mech_list: __MECHANISM1 ...__
-----
-
-`sasldb_path`:: The name of the SASL database to use.
-+
-For example:
-+
-[options="nowrap"]
-----
-sasldb_path: qdrouterd.sasldb
-----
-
-`mech_list`:: The SASL mechanisms to enable for authentication. To add multiple mechanisms, separate each entry with a space.
-+
-For example:
-+
-[options="nowrap"]
-----
-mech_list: ANONYMOUS DIGEST-MD5 EXTERNAL PLAIN
-----
-// Where can users find a list of supported mechanisms?
---
diff --git a/docs/books/modules/user-guide/enabling-username-password-authentication.adoc b/docs/books/modules/user-guide/enabling-username-password-authentication.adoc
index a4503ff..48449d0 100644
--- a/docs/books/modules/user-guide/enabling-username-password-authentication.adoc
+++ b/docs/books/modules/user-guide/enabling-username-password-authentication.adoc
@@ -28,12 +28,6 @@
.Prerequisites
-* A SASL database containing the usernames and passwords exists.
-
-* The SASL configuration file is configured.
-+
-By default, this file should be `/etc/sasl2/qdrouterd.conf`.
-
* The `cyrus-sasl-plain` plugin is installed.
+
Cyrus SASL uses plugins to support specific SASL mechanisms. Before you can use a particular SASL mechanism, the relevant plugin must be installed.
@@ -45,7 +39,39 @@
.Procedure
-include::{FragmentDir}/fragment-router-open-config-file-step.adoc[]
+. If necessary, add the user names and passwords to the SASL database.
++
+--
+This example adds a new user (\user1@example.com) to the SASL database (qdrouterd.sasldb):
+
+[options="nowrap",subs="+quotes"]
+----
+$ sudo saslpasswd2 -c -f qdrouterd.sasldb -u example.com user1
+----
+
+[NOTE]
+====
+The full user name is the user name you entered plus the domain name (`__<user-name>__`@`__<domain-name>__`). Providing a domain name is not required when you add a user to the database, but if you do not provide one, a default domain will be added automatically (the hostname of the machine on which the tool is running).
+====
+--
+
+. Open the `/etc/sasl2/qdrouterd.conf` configuration file.
++
+--
+This example shows a `/etc/sasl2/qdrouterd.conf` configuration file:
+
+[options="nowrap",subs="+quotes"]
+----
+pwcheck_method: auxprop
+auxprop_plugin: sasldb
+sasldb_path: qdrouterd.sasldb
+mech_list: ANONYMOUS DIGEST-MD5 EXTERNAL PLAIN GSSAPI
+----
+--
+
+. Verify that the `mech_list` attribute contains the `PLAIN` mechanism.
+
+. Open the `{RouterConfigFile}` configuration file.
. In the `router` section, specify the path to the SASL configuration file.
+
diff --git a/docs/books/modules/user-guide/enabling-vhost-policies.adoc b/docs/books/modules/user-guide/enabling-vhost-policies.adoc
new file mode 100644
index 0000000..c77b135
--- /dev/null
+++ b/docs/books/modules/user-guide/enabling-vhost-policies.adoc
@@ -0,0 +1,51 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// setting-connection-resource-limits-messaging-endpoints.adoc
+
+[id='enabling-vhost-policies-{context}']
+= Enabling vhost policies
+
+You must enable the router to use vhost policies before you can create the policies.
+
+.Procedure
+
+* In the `{RouterConfigFile}` configuration file, add a `policy` section if one does not exist, and enable vhost policies for the router.
++
+--
+[options="nowrap",subs="+quotes"]
+----
+policy {
+ ...
+ enableVhostPolicy: true
+ enableVhostNamePatterns: true
+ defaultVhost: $default
+}
+----
+`enableVhostPolicy`::
+Enables the router to enforce the connection denials and resource limits defined in the configured vhost policies. The default is `false`, which means that the router will not enforce any vhost policies.
+
+`enableVhostNamePatterns`::
+Enables pattern matching for vhost hostnames. If set to `true`, you can use wildcards to specify a range of hostnames for a vhost. If set to `false`, vhost hostnames are treated as literal strings. This means that you must specify the exact hostname for each vhost. The default is `false`.
+
+`defaultVhost`::
+The name of the default vhost policy, which is applied to any connection for which a vhost policy has not been configured. The default is `$default`. If `defaultVhost` is not defined, then default vhost processing is disabled.
+--
diff --git a/docs/books/modules/user-guide/viewing-default-router-configuration-file.adoc b/docs/books/modules/user-guide/exploring-default-router-configuration-file.adoc
similarity index 94%
rename from docs/books/modules/user-guide/viewing-default-router-configuration-file.adoc
rename to docs/books/modules/user-guide/exploring-default-router-configuration-file.adoc
index 5963098..47872a4 100644
--- a/docs/books/modules/user-guide/viewing-default-router-configuration-file.adoc
+++ b/docs/books/modules/user-guide/exploring-default-router-configuration-file.adoc
@@ -21,8 +21,8 @@
//
// getting-started.adoc
-[id='viewing-default-router-configuration-file-{context}']
-= Viewing the default router configuration file
+[id='exploring-default-router-configuration-file-{context}']
+= Exploring the default router configuration file
The router's configuration file (`qdrouterd.conf`) controls the way in which the router functions. The default configuration file contains the minimum number of settings required for the router to run. As you become more familiar with the router, you can add to or change these settings, or create your own configuration files.
@@ -34,7 +34,7 @@
.Procedure
-. Open the following file: `/etc/qpid-dispatch/qdrouterd.conf`.
+. Open the following file: `{RouterConfigFile}`.
+
--
When {RouterName} is installed, `qdrouterd.conf` is installed in this directory. When the router is started, it runs with the settings defined in this file.
@@ -43,7 +43,7 @@
. Review the default settings in `qdrouterd.conf`.
+
--
-.Default Configuration File
+.Default configuration file
[options="nowrap"]
----
router {
diff --git a/docs/books/modules/user-guide/handling-undeliverable-messages-for-address.adoc b/docs/books/modules/user-guide/handling-undeliverable-messages-for-address.adoc
new file mode 100644
index 0000000..5e2da06
--- /dev/null
+++ b/docs/books/modules/user-guide/handling-undeliverable-messages-for-address.adoc
@@ -0,0 +1,88 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// configuring-brokered-messaging.adoc
+
+[id='handling-undeliverable-messages-{context}']
+= Handling undeliverable messages
+
+You handle undeliverable messages for an address by configuring autolinks that point to _fallback destinations_. A fallback destination (such as a queue on a broker) stores messages that are not directly routable to any consumers.
+
+During normal message delivery, {RouterName} delivers messages to the consumers that are attached to the router network. However, if no consumers are reachable, the messages are diverted to any fallback destinations that were configured for the address (if the autolinks that point to the fallback destinations are active). When a consumer reconnects and becomes reachable again, it receives the messages stored at the fallback destination.
+
+[NOTE]
+====
+{RouterName} preserves the original delivery order for messages stored at a fallback destination. However, when a consumer reconnects, any new messages produced while the queue is draining will be interleaved with the messages stored at the fallback destination.
+====
+
+.Prerequisites
+
+* The router is connected to a broker.
++
+For more information, see xref:connecting-to-external-amqp-containers-{context}[].
+
+.Procedure
+
+This procedure enables fallback for an address and configures autolinks to connect to the broker queue that provides the fallback destination for the address.
+
+. In the `{RouterConfigFile}` configuration file, enable fallback destinations for the address.
++
+[options="nowrap",subs="+quotes"]
+----
+address {
+ prefix: my_address
+ enableFallback: yes
+}
+----
+
+. Add an _outgoing_ autolink to a queue on the broker.
++
+--
+For the address for which you enabled fallback, if messages are not routable to any consumers, the router will use this autolink to send the messages to a queue on the broker.
+
+[options="nowrap",subs="+quotes"]
+----
+autoLink {
+ address: my_address.2
+ direction: out
+ connection: my_broker
+ fallback: yes
+}
+----
+--
+
+. If you want the router to send queued messages to attached consumers as soon as they connect to the router network, add an _incoming_ autolink.
++
+--
+As soon as a consumer attaches to the router, it will receive the messages stored in the broker queue, along with any new messages sent by the producer. The original delivery order of the queued messages is preserved; however, the queued messages will be interleaved with the new messages.
+
+If you do not add the incoming autolink, the messages will be stored on the broker, but will not be sent to consumers when they attach to the router.
+
+[options="nowrap",subs="+quotes"]
+----
+autoLink {
+ address: my_address.2
+ direction: in
+ connection: my_broker
+ fallback: yes
+}
+----
+--
diff --git a/docs/books/modules/user-guide/how-policies-enforce-connection-resource-limits.adoc b/docs/books/modules/user-guide/how-policies-enforce-connection-resource-limits.adoc
new file mode 100644
index 0000000..162496d
--- /dev/null
+++ b/docs/books/modules/user-guide/how-policies-enforce-connection-resource-limits.adoc
@@ -0,0 +1,35 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// authorizing-access-messaging-resources.adoc
+
+[id='how-policies-enforce-connection-resource-limits-{context}']
+= How policies enforce connection and resource limits
+
+{RouterName} uses policies to determine whether to permit a connection, and if it is permitted, to apply the appropriate resource limits.
+
+When a client creates a connection to a router, the router first determines whether to allow or deny the connection. This decision is based on the following criteria:
+
+* Whether the connection will exceed the router’s global connection limit (defined in the global policy)
+
+* Whether the connection will exceed the vhost’s connection limits (defined in the vhost policy that matches the host to which the connection is directed)
+
+If the connection is allowed, the router assigns the user (the authenticated user name from the connection) to a user group, and enforces the user group’s resource limits for the lifetime of the connection.
diff --git a/docs/books/modules/user-guide/how-router-enables-brokered-messaging.adoc b/docs/books/modules/user-guide/how-router-enables-brokered-messaging.adoc
new file mode 100644
index 0000000..67caea7
--- /dev/null
+++ b/docs/books/modules/user-guide/how-router-enables-brokered-messaging.adoc
@@ -0,0 +1,41 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// configuring-brokered-messaging.adoc
+
+[id='how-router-enables-brokered-messaging-{context}']
+= How {RouterName} enables brokered messaging
+
+Brokered messaging enables {RouterName} to store messages on a broker queue. This requires a connection to the broker, a _waypoint_ address to represent the broker queue, and _autolinks_ to attach to the waypoint address.
+
+An autolink is a link that is automatically created by the router to attach to a waypoint address. With autolinks, client traffic is handled on the router, not the broker. Clients attach their links to the router, and then the router uses internal autolinks to connect to the queue on the broker. Therefore, the queue will always have a single producer and a single consumer regardless of how many clients are attached to the router.
+
+.Brokered messaging
+image::brokered-messaging.png[Brokered Messaging, align="center"]
+
+In this diagram, the sender connects to the router and sends messages to my_queue. The router attaches an outgoing link to the broker, and then sends the messages to my_queue. Later, the receiver connects to the router and requests messages from my_queue. The router attaches an incoming link to the broker to receive the messages from my_queue, and then delivers them to the receiver.
+
+You can also route messages to a _sharded queue_, which is a single, logical queue comprised of multiple, underlying physical queues. Using queue sharding, it is possible to distribute a single queue over multiple brokers. Clients can connect to any of the brokers that hold a shard to send and receive messages.
+
+.Brokered messaging with sharded queue
+image::sharded-queue-02.png[Brokered Messaging with Sharded Queue, align="center"]
+
+In this diagram, a sharded queue (my_queue) is distributed across two brokers. The router is connected to the clients and to both brokers. The sender connects to the router and sends messages to my_queue. The router attaches an outgoing link to each broker, and then sends messages to each shard (by default, the routing distribution is `balanced`). Later, the receiver connects to the router and requests all of the messages from my_queue. The router attaches an incoming link to one of the brokers to receive the messages from my_queue, and then delivers them to the receiver.
diff --git a/docs/books/modules/user-guide/how-routers-route-messages.adoc b/docs/books/modules/user-guide/how-routers-route-messages.adoc
index 34c596b..ba95650 100644
--- a/docs/books/modules/user-guide/how-routers-route-messages.adoc
+++ b/docs/books/modules/user-guide/how-routers-route-messages.adoc
@@ -24,7 +24,7 @@
[id='how-routers-route-messages-{context}']
= How routers route messages
-In a router network, _routing_ is the process by which messages are delivered to their destinations. To accomplish this, {RouterName} offers two different routing mechanisms:
+In a router network, _routing_ is the process by which messages are delivered to their destinations. To accomplish this, {RouterName} offers two different routing mechanisms:
Message routing::
Message routing enables you to distribute messages in anycast and multicast patterns. These patterns can be used for both direct routing, in which the router distributes messages between clients without a message broker, and indirect routing, in which the router enables clients to exchange messages through a message broker.
@@ -45,7 +45,7 @@
Sharding messages from one producer might cause that producer’s messages to be received in a different order than the order in which they were sent.
--
-Link routing::
+Link routing::
Link routing enables you to establish a dedicated, virtual "path" between a sender and receiver that travels through the router network. Link routes are typically used to connect clients to message brokers in scenarios in which a direct connection is unfeasible. Therefore, link routes enable messaging capabilities that are not possible with message routing, such as:
+
--
@@ -68,6 +68,6 @@
.Additional resources
-* xref:configuring-message-routing[]
+* xref:configuring-message-routing-{context}[]
-* xref:configuring-link-routing[]
+* xref:creating-link-routes-{context}[]
diff --git a/docs/books/modules/user-guide/installing-router.adoc b/docs/books/modules/user-guide/installing-router-linux.adoc
similarity index 91%
rename from docs/books/modules/user-guide/installing-router.adoc
rename to docs/books/modules/user-guide/installing-router-linux.adoc
index f870357..89cae92 100644
--- a/docs/books/modules/user-guide/installing-router.adoc
+++ b/docs/books/modules/user-guide/installing-router-linux.adoc
@@ -21,8 +21,8 @@
//
// getting-started.adoc
-[id='installing-router-{context}']
-= Installing {RouterName}
+[id='installing-router-linux-{context}']
+= Installing {RouterName} on {RouterPlatform}
include::{FragmentDir}/fragment-router-install-intro.adoc[]
diff --git a/docs/books/modules/user-guide/link-route-addresses.adoc b/docs/books/modules/user-guide/link-route-addresses.adoc
new file mode 100644
index 0000000..3b8b651
--- /dev/null
+++ b/docs/books/modules/user-guide/link-route-addresses.adoc
@@ -0,0 +1,31 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// understanding-link-routing.adoc
+
+[id='link-route-addresses-{context}']
+= Link route addresses
+
+A link route address represents a broker queue, topic, or other service. When a client attaches a link route address to a router, the router propagates a link attachment to the broker resource identified by the address.
+
+Using link route addresses, the router network does not participate in
+aggregated message distribution. The router simply passes message
+delivery and settlement between the two end points.
diff --git a/docs/books/modules/user-guide/link-route-example.adoc b/docs/books/modules/user-guide/link-route-example.adoc
new file mode 100644
index 0000000..0b2c708
--- /dev/null
+++ b/docs/books/modules/user-guide/link-route-example.adoc
@@ -0,0 +1,115 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// configuring-link-routing.adoc
+
+[id='link-route-example-{context}']
+= Link route example: Connecting clients and brokers on different networks
+
+This example shows how a link route can connect a client to a message broker that is on a different private network.
+
+.Router network with isolated clients
+----
+
+ Public Network
+ +-----------------+
+ | +-----+ |
+ | B1 | Rp | |
+ | +/--\-+ |
+ | / \ |
+ | / \ |
+ +----/--------\---+
+ / \
+ / \
+ / \
+ Private Net A / \ Private Net B
+ +--------------/--+ +---\-------------+
+ | +---/-+ | | +--\--+ |
+ | B2 | Ra | | | | Rb | C1 |
+ | +-----+ | | +-----+ |
+ | | | |
+ | | | |
+ +-----------------+ +-----------------+
+----
+
+Client `C1` is constrained by firewall policy to connect to the router in its own network (`Rb`). However, it can use a link route to access queues, topics, and any other AMQP services that are provided on message brokers `B1` and `B2` -- even though they are on different networks.
+
+In this example, client `C1` needs to receive messages from `b2.event-queue`, which is hosted on broker `B2` in `Private Net A`. A link route connects the client and broker even though neither of them is aware that there is a router network between them.
+
+[discrete]
+== Router configuration
+
+To enable client `C1` to receive messages from `b2.event-queue` on broker `B2`, router `Ra` must be able to do the following:
+
+* Connect to broker `B2`
+* Route links to and from broker `B2`
+* Advertise itself to the router network as a valid destination for links that have a `b2.event-queue` address
+
+The relevant part of the configuration file for router `Ra` shows the following:
+
+--
+[options="nowrap"]
+----
+connector { // <1>
+ name: broker
+ role: route-container
+ host: 192.0.2.1
+ port: 61617
+ saslMechanisms: ANONYMOUS
+}
+
+linkRoute { // <2>
+ prefix: b2
+ direction: in
+ connection: broker
+}
+
+linkRoute { // <3>
+ prefix: b2
+ direction: out
+ connection: broker
+}
+----
+<1> The outgoing connection from the router to broker `B2`. The `route-container` role enables the router to connect to an external AMQP container (in this case, a broker).
+<2> The incoming link route for receiving links from client senders. Any sender with a target whose address begins with `b2` will be routed to broker `B2` using the `broker` connector.
+<3> The outgoing link route for sending links to client receivers. Any receivers whose source address begins with `b2` will be routed to broker `B2` using the `broker` connector.
+--
+
+This configuration enables router `Ra` to advertise itself as a valid destination for targets and sources starting with `b2`. It also enables the router to connect to broker `B2`, and to route links to and from queues starting with the `b2` prefix.
+
+[NOTE]
+====
+While not required, routers `Rp` and `Rb` should also have the same configuration.
+====
+
+[discrete]
+== How the client receives messages
+
+By using the configured link route, client `C1` can receive messages from broker `B2` even though they are on different networks.
+
+Router `Ra` establishes a connection to broker `B2`. Once the connection is open, `Ra` tells the other routers (`Rp` and `Rb`) that it is a valid destination for link routes to the `b2` prefix. This means that sender and receiver links attached to `Rb` or `Rp` will be routed along the shortest path to `Ra`, which then routes them to broker `B2`.
+
+To receive messages from the `b2.event-queue` on broker `B2`, client `C1` attaches a receiver link with a source address of `b2.event-queue` to its local router, `Rb`. Because the address matches the `b2` prefix, `Rb` routes the link to `Rp`, which is the next hop in the route to its destination. `Rp` routes the link to `Ra`, which routes it to broker `B2`. Client `C1` now has a receiver established, and it can begin receiving messages.
+
+[NOTE]
+====
+If broker `B2` is unavailable for any reason, router `Ra` will not advertise itself as a destination for `b2` addresses. In this case, routers `Rb` and `Rp` will reject link attaches that should be routed to broker `B2` with an error message indicating that there is no route available to the destination.
+====
diff --git a/docs/books/modules/user-guide/installing-router.adoc b/docs/books/modules/user-guide/link-routing-flow-control.adoc
similarity index 61%
copy from docs/books/modules/user-guide/installing-router.adoc
copy to docs/books/modules/user-guide/link-routing-flow-control.adoc
index f870357..9cff0bd 100644
--- a/docs/books/modules/user-guide/installing-router.adoc
+++ b/docs/books/modules/user-guide/link-routing-flow-control.adoc
@@ -17,15 +17,11 @@
under the License
////
-// Module included in the following assemblies:
+// This module is included in the following assemblies:
//
-// getting-started.adoc
+// understanding-link-routing.adoc
-[id='installing-router-{context}']
-= Installing {RouterName}
+[id='link-routing-flow-control-{context}']
+= Link routing flow control
-include::{FragmentDir}/fragment-router-install-intro.adoc[]
-
-.Procedure
-
-include::{FragmentDir}/fragment-router-install-steps.adoc[]
+Unlike message routing, with link routing, the sender and receiver handle flow control directly: the receiver grants link credits, which is the number of messages it is able to receive. The router sends them directly to the sender, and then the sender sends the messages based on the credits that the receiver granted.
diff --git a/docs/books/modules/user-guide/logging-modules.adoc b/docs/books/modules/user-guide/logging-modules.adoc
new file mode 100644
index 0000000..cace339
--- /dev/null
+++ b/docs/books/modules/user-guide/logging-modules.adoc
@@ -0,0 +1,66 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// configuring-logging.adoc
+
+[id='logging-modules-{context}']
+= Logging modules
+
+{RouterName} logs are broken into different categories called _logging modules_. Each module provides important information about a particular aspect of {RouterName}.
+
+`DEFAULT`::
+The default module. This module applies defaults to all of the other logging modules.
+
+`ROUTER`::
+This module provides information and statistics about the local router. This includes how the router connects to other routers in the network, and information about the remote destinations that are directly reachable from the router (link routes, waypoints, autolinks, and so on).
+
+`ROUTER_HELLO`::
+This module provides information about the _Hello_ protocol used by interior routers to exchange Hello messages, which include information about the router's ID and a list of its reachable neighbors (the other routers with which this router has bidirectional connectivity).
+
+`ROUTER_LS`::
+This module provides information about link-state data between routers, including Router Advertisement (RA), Link State Request (LSR), and Link State Update (LSU) messages.
++
+Periodically, each router sends an LSR to the other routers and receives an LSU with the requested information. Exchanging the above information, each router can compute the next hops in the topology, and the related costs.
+
+`ROUTER_MA`::
+This module provides information about the exchange of mobile address information between routers, including Mobile Address Request (MAR) and Mobile Address Update (MAU) messages exchanged between routers. You can use this log to monitor the state of mobile addresses attached to each router.
+
+`MESSAGE`::
+This module provides information about AMQP messages sent and received by the router, including information about the address, body, and link. You can use this log to find high-level information about messages on a particular router.
+
+`SERVER`::
+This module provides information about how the router is listening for and connecting to other containers in the network (such as clients, routers, and brokers). This information includes the state of AMQP messages sent and received by the broker (open, begin, attach, transfer, flow, and so on), and the related content of those messages.
+
+`AGENT`::
+This module provides information about configuration changes made to the router from either editing the router's configuration file or using `qdmanage`.
+
+`CONTAINER`::
+This module provides information about the nodes related to the router. This includes only the AMQP relay node.
+
+`ERROR`::
+This module provides detailed information about error conditions encountered during execution.
+
+`POLICY`::
+This module provides information about policies that have been configured for the router.
+
+.Additional resources
+
+* For examples of these logging modules, see xref:troubleshooting-using-logs-{context}[].
diff --git a/docs/books/modules/user-guide/logging.adoc b/docs/books/modules/user-guide/logging.adoc
deleted file mode 100644
index d5a8c31..0000000
--- a/docs/books/modules/user-guide/logging.adoc
+++ /dev/null
@@ -1,328 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License
-////
-
-[id='logging']
-= Logging
-
-Logging enables you to diagnose error and performance issues with {RouterName}.
-
-{RouterName} consists of internal modules that provide important information about the router. For each module, you can specify logging levels, the format of the log file, and the location to which the logs should be written.
-
-[id='logging-modules-you-can-configure']
-== Logging Modules
-
-{RouterName} logs are broken into different categories called _logging modules_. Each module provides important information about a particular aspect of {RouterName}.
-
-=== The `DEFAULT` Logging Module
-
-The default module. This module applies defaults to all of the other logging modules.
-
-=== The `ROUTER` Logging Module
-
-This module provides information and statistics about the local router. This includes how the router connects to other routers in the network, and information about the remote destinations that are directly reachable from the router (link routes, waypoints, autolinks, and so on).
-
-.Using the `ROUTER` log to trace connections and links
-====
-In this example, `ROUTER` logs show the lifecycle of a connection and a link that is associated with it.
-
-[options="nowrap"]
-----
-2019-04-05 14:54:38.037248 -0400 ROUTER (info) [C1] Connection Opened: dir=in host=127.0.0.1:55440 vhost= encrypted=no auth=no user=anonymous container_id=95e55424-6c0a-4a5c-8848-65a3ea5cc25a props= // <1>
-2019-04-05 14:54:38.038137 -0400 ROUTER (info) [C1][L6] Link attached: dir=in source={<none> expire:sess} target={$management expire:sess} // <2>
-2019-04-05 14:54:38.041103 -0400 ROUTER (info) [C1][L6] Link lost: del=1 presett=0 psdrop=0 acc=1 rej=0 rel=0 mod=0 delay1=0 delay10=0 // <3>
-2019-04-05 14:54:38.041154 -0400 ROUTER (info) [C1] Connection Closed // <4>
-----
-<1> The connection is opened. Each connection has a unique ID (`C1`). The log also shows some information about the connection.
-<2> A link is attached over the connection. The link is identified with a unique ID (`L6`). The log also shows the direction of the link, and the source and target addresses.
-<3> The link is detached. The log shows the link's terminal statistics.
-<4> The connection is closed.
-====
-
-=== The `ROUTER_HELLO` Logging Module
-
-This module provides information about the _Hello_ protocol used by interior routers to exchange Hello messages, which include information about the router's ID and a list of its reachable neighbors (the other routers with which this router has bidirectional connectivity).
-
-The logs for this module are helpful for monitoring or resolving issues in the network topology, and for determining to which other routers a router is connected, and the hop-cost for each of those connections.
-
-In this example, on `Router.A`, the `ROUTER_HELLO` log shows that it is connected to `Router.B`, and that `Router.B` is connected to `Router.A` and `Router.C`:
-
-[options="nowrap"]
-----
-Tue Jun 7 13:50:21 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C']) // <1>
-Tue Jun 7 13:50:21 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B']) // <2>
-Tue Jun 7 13:50:22 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C'])
-Tue Jun 7 13:50:22 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B'])
-----
-<1> `Router.A` received a Hello message from `Router.B`, which can see `Router.A` and `Router.C`.
-<2> `Router.A` sent a Hello message to `Router.B`, which is the only router it can see.
-
-On `Router.B`, the `ROUTER_HELLO` log shows the same router topology from a different perspective:
-
-[options="nowrap"]
-----
-Tue Jun 7 13:50:18 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C']) // <1>
-Tue Jun 7 13:50:18 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B']) // <2>
-Tue Jun 7 13:50:19 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.C area=0 inst=1465307411 seen=['Router.B']) // <3>
-----
-<1> `Router.B` sent a Hello message to `Router.A` and `Router.C`.
-<2> `Router.B` received a Hello message from `Router.A`, which can only see `Router.B`.
-<3> `Router.B` received a Hello message from `Router.C`, which can only see `Router.B`.
-
-=== The `ROUTER_LS` Logging Module
-
-This module provides information about link-state data between routers, including Router Advertisement (RA), Link State Request (LSR), and Link State Update (LSU) messages.
-
-Periodically, each router sends an LSR to the other routers and receives an LSU with the requested information. Exchanging the above information, each router can compute the next hops in the topology, and the related costs.
-
-This example shows the RA, LSR, and LSU messages sent between three routers:
-
-[options="nowrap"]
-----
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.C
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.B
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: RA(id=Router.A area=0 inst=1465308600 ls_seq=1 mobile_seq=1) // <1>
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSU(id=Router.B area=0 inst=1465308595 ls_seq=2 ls=LS(id=Router.B area=0 ls_seq=2 peers={'Router.A': 1L, 'Router.C': 1L})) // <2>
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSR(id=Router.B area=0)
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSU(id=Router.A area=0 inst=1465308600 ls_seq=1 ls=LS(id=Router.A area=0 ls_seq=1 peers={'Router.B': 1}))
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: RA(id=Router.C area=0 inst=1465308592 ls_seq=1 mobile_seq=0)
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.C
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSR(id=Router.C area=0) // <3>
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSU(id=Router.A area=0 inst=1465308600 ls_seq=1 ls=LS(id=Router.A area=0 ls_seq=1 peers={'Router.B': 1}))
-Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSU(id=Router.C area=0 inst=1465308592 ls_seq=1 ls=LS(id=Router.C area=0 ls_seq=1 peers={'Router.B': 1L})) // <4>
-Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed next hops: {'Router.C': 'Router.B', 'Router.B': 'Router.B'} // <5>
-Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed costs: {'Router.C': 2L, 'Router.B': 1}
-Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed valid origins: {'Router.C': [], 'Router.B': []}
-----
-<1> `Router.A` sent LSR requests and an RA advertisement to the other routers on the network.
-<2> `Router.A` received an LSU from `Router.B`, which has two peers: `Router.A`, and `Router.C` (with a cost of `1`).
-<3> `Router.A` received an LSR from both `Router.B` and `Router.C`, and replied with an LSU.
-<4> `Router.A` received an LSU from `Router.C`, which only has one peer: `Router.B` (with a cost of `1`).
-<5> After the LSR and LSU messages are exchanged, `Router.A` computed the router topology with the related costs.
-
-=== The `ROUTER_MA` Logging Module
-
-This module provides information about the exchange of mobile address information between routers, including Mobile Address Request (MAR) and Mobile Address Update (MAU) messages exchanged between routers. You can use this log to monitor the state of mobile addresses attached to each router.
-
-This example shows the MAR and MAU messages sent between three routers:
-
-[options="nowrap"]
-----
-Tue Jun 7 14:27:20 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[]) // <1>
-Tue Jun 7 14:27:21 2016 ROUTER_MA (trace) RCVD: MAR(id=Router.C area=0 have_seq=0) // <2>
-Tue Jun 7 14:27:21 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[])
-Tue Jun 7 14:27:22 2016 ROUTER_MA (trace) RCVD: MAR(id=Router.B area=0 have_seq=0) // <3>
-Tue Jun 7 14:27:22 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[])
-Tue Jun 7 14:27:39 2016 ROUTER_MA (trace) RCVD: MAU(id=Router.C area=0 mobile_seq=1 add=['M0my_test'] del=[]) // <4>
-Tue Jun 7 14:27:51 2016 ROUTER_MA (trace) RCVD: MAU(id=Router.C area=0 mobile_seq=2 add=[] del=['M0my_test']) // <5>
-----
-<1> `Router.A` sent MAU messages to the other routers in the network to notify them about the addresses added for `my_queue` and `my_queue_wp`.
-<2> `Router.A` received a MAR message in response from `Router.C`.
-<3> `Router.A` received another MAR message in response from `Router.B`.
-<4> `Router.C` sent a MAU message to notify the other routers that it added and address for `my_test`.
-<5> `Router.C` sent another MAU message to notify the other routers that it deleted the address for `my_test` (because the receiver is detached).
-
-=== The `MESSAGE` Logging Module
-
-This module provides information about AMQP messages sent and received by the router, including information about the address, body, and link. You can use this log to find high-level information about messages on a particular router.
-
-In this example, `Router.A` has sent and received some messages related to the Hello protocol, and sent and received some other messages on a link for a mobile address:
-
-[options="nowrap"]
-----
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_topo/0/Router.B/qdrouter' body='\d1\00\00\00\1b\00\00\00\04\a1\02id\a1\08R'} on link qdlink.p9XmBm19uDqx50R
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Received Message{to='amqp:/_topo/0/Router.A/qdrouter' body='\d1\00\00\00\8e\00\00\00
-\a1\06ls_se'} on link qdlink.phMsJOq7YaFsGAG
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Received Message{ body='\d1\00\00\00\10\00\00\00\02\a1\08seque'} on link qdlink.FYHqBX+TtwXZHfV
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{ body='\d1\00\00\00\10\00\00\00\02\a1\08seque'} on link qdlink.yU1tnPs5KbMlieM
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_local/qdhello' body='\d1\00\00\00G\00\00\00\08\a1\04seen\d0'} on link qdlink.p9XmBm19uDqx50R
-Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_topo/0/Router.C/qdrouter' body='\d1\00\00\00\1b\00\00\00\04\a1\02id\a1\08R'} on link qdlink.p9XmBm19uDqx50R
-----
-
-=== The `SERVER` Logging Module
-
-This module provides information about how the router is listening for and connecting to other containers in the network (such as clients, routers, and brokers). This information includes the state of AMQP messages sent and received by the broker (open, begin, attach, transfer, flow, and so on), and the related content of those messages.
-
-For example, this log shows details about how the router handled a link attachment:
-
-[options="nowrap"]
-----
-Tue Jun 7 14:39:52 2016 SERVER (trace) [2]: <- AMQP
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]: <- AMQP
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:0 <- @open(16) [container-id="Router.B", max-frame-size=16384, channel-max=32767, idle-time-out=8000, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router", :version="0.6.0"}]
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=15, outgoing-window=2147483647]
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x1e\x02\x00\x00\x00\x00S\x11\xd0\x00\x00\x00\x0e\x00\x00\x00\x04@R\x00R\x0fp\x7f\xff\xff\xff"
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:1 -> @begin(17) [next-outgoing-id=0, incoming-window=15, outgoing-window=2147483647]
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x1e\x02\x00\x00\x01\x00S\x11\xd0\x00\x00\x00\x0e\x00\x00\x00\x04@R\x00R\x0fp\x7f\xff\xff\xff"
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:0 -> @attach(18) [name="qdlink.uSSeXPSfTHhxo8d", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, capabilities=:"qd.router"], target=@target(41) [durable=0, expiry-policy=:"link-detach", timeout=0, dynamic=false, capabilities=:"qd.router"], initial-delivery-count=0]
-Tue Jun 7 14:39:52 2016 SERVER (trace) [1]:RAW: "\x00\x00\x00\x91\x02\x00\x00\x00\x00S\x12\xd0\x00\x00\x00\x81\x00\x00\x00\x0a\xa1\x16qdlink.uSSeXPSfTHhxo8dR\x00AP\x02P\x00\x00S(\xd0\x00\x00\x00'\x00\x00\x00\x0b@R\x00\xa3\x0blink-detachR\x00B@@@@@\xa3\x09qd.router\x00S)\xd0\x00\x00\x00#\x00\x00\x00\x07@R\x00\xa3\x0blink-detachR\x00B@\xa3\x09qd.router@@R\x00"
-----
-
-=== The `AGENT` Logging Module
-
-This module provides information about configuration changes made to the router from either editing the router's configuration file or using `qdmanage`.
-
-In this example, on `Router.A`, `address`, `linkRoute`, and `autoLink` entities were added to the router's configuration file. When the router was started, the `AGENT` module applied these changes, and they are now viewable in the log:
-
-[options="nowrap"]
-----
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: ConnectorEntity(addr=127.0.0.1, allowRedirect=True, cost=1, host=127.0.0.1, identity=connector/127.0.0.1:5672:BROKER, idleTimeoutSeconds=16, maxFrameSize=65536, name=BROKER, port=5672, role=route-container, stripAnnotations=both, type=org.apache.qpid.dispatch.connector, verifyHostname=True)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAddressEntity(distribution=closest, identity=router.config.address/0, name=router.config.address/0, prefix=my_address, type=org.apache.qpid.dispatch.router.config.address, waypoint=False)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAddressEntity(distribution=balanced, identity=router.config.address/1, name=router.config.address/1, prefix=my_queue_wp, type=org.apache.qpid.dispatch.router.config.address, waypoint=True)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigLinkrouteEntity(connection=BROKER, direction=in, distribution=linkBalanced, identity=router.config.linkRoute/0, name=router.config.linkRoute/0, prefix=my_queue, type=org.apache.qpid.dispatch.router.config.linkRoute)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigLinkrouteEntity(connection=BROKER, direction=out, distribution=linkBalanced, identity=router.config.linkRoute/1, name=router.config.linkRoute/1, prefix=my_queue, type=org.apache.qpid.dispatch.router.config.linkRoute)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAutolinkEntity(address=my_queue_wp, connection=BROKER, direction=in, identity=router.config.autoLink/0, name=router.config.autoLink/0, type=org.apache.qpid.dispatch.router.config.autoLink)
-Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAutolinkEntity(address=my_queue_wp, connection=BROKER, direction=out, identity=router.config.autoLink/1, name=router.config.autoLink/1, type=org.apache.qpid.dispatch.router.config.autoLink)
-----
-
-=== The `CONTAINER` Logging Module
-
-This module provides information about the nodes related to the router. This includes only the AMQP relay node.
-
-[options="nowrap"]
-----
-Tue Jun 7 14:46:18 2016 CONTAINER (trace) Container Initialized
-Tue Jun 7 14:46:18 2016 CONTAINER (trace) Node Type Registered - router
-Tue Jun 7 14:46:18 2016 CONTAINER (trace) Node of type 'router' installed as default node
-----
-
-=== The `ERROR` Logging Module
-
-This module provides detailed information about error conditions encountered during execution.
-
-In this example, `Router.A` failed to start when an incorrect path was specified for the router's configuration file:
-
-[options="nowrap"]
-----
-$ sudo qdrouterd --conf xxx
-Wed Jun 15 09:53:28 2016 ERROR (error) Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
-Wed Jun 15 09:53:28 2016 ERROR (error) Traceback (most recent call last):
- File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 155, in configure_dispatch
- config = Config(filename)
- File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 41, in __init__
- self.load(filename, raw_json)
- File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 123, in load
- with open(source) as f:
-Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
-
-Wed Jun 15 09:53:28 2016 MAIN (critical) Router start-up failed: Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
-qdrouterd: Python: Exception: Cannot load configuration file xxx: [Errno 2] No such file or directory: 'xxx'
-----
-
-=== The `POLICY` Logging Module
-
-This module provides information about policies that have been configured for the router.
-
-In this example, `Router.A` has no limits on maximum connections, and the default application policy is disabled:
-
-[options="nowrap"]
-----
-Tue Jun 7 15:07:32 2016 POLICY (info) Policy configured maximumConnections: 0, policyFolder: '', access rules enabled: 'false'
-Tue Jun 7 15:07:32 2016 POLICY (info) Policy fallback defaultApplication is disabled
-----
-
-[id='configure-default-logging']
-== Configuring Logging
-
-You can specify the types of events that should be logged, the format of the log entries, and where those entries should be sent.
-
-.Procedure
-
-. In the router's configuration file, add a `log` section to set the default logging properties:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-log {
- module: DEFAULT
- enable: _LOGGING_LEVEL_
- includeTimestamp: yes
- ...
-}
-----
-
-`module`:: Specify `DEFAULT`.
-`enable`:: The logging level. You can specify any of the following levels (from lowest to highest):
-+
-//tag::logging-levels[]
-* `trace` - provides the most information, but significantly affects system performance
-* `debug` - useful for debugging, but affects system performance
-* `info` - provides general information without affecting system performance
-* `notice` - provides general information, but is less verbose than `info`
-* `warning` - provides information about issues you should be aware of, but which are not errors
-* `error` - error conditions that you should address
-* `critical` - critical system issues that you must address immediately
-
-+
-To specify multiple levels, use a comma-separated list. You can also use `+` to specify a level and all levels above it. For example, `trace,debug,warning+` enables trace, debug, warning, error, and critical levels. For default logging, you should typically use the `info+` or `notice+` level. These levels will provide general information, warnings, and errors for all modules without affecting the performance of {RouterName}.
-//end::logging-levels[]
-`includeTimestamp`:: Set this to `yes` to include the timestamp in all logs.
-
-For information about additional log attributes, see link:{qdrouterdConfManPageUrl}#_log[log] in the `qdrouterd.conf` man page.
---
-
-. Add an additional `log` section for each logging module that should not follow the default logging configuration:
-+
---
-
-[options="nowrap",subs="+quotes"]
-----
-log {
- module: _MODULE_NAME_
- enable: _LOGGING_LEVEL_
- ...
-}
-----
-
-`module`:: The name of the module for which you are configuring logging. For a list of valid modules, see xref:logging-modules-you-can-configure[].
-`enable`:: The logging level. You can specify any of the following levels (from lowest to highest):
-+
-include::logging.adoc[tags=logging-levels]
-
-For information about additional log attributes, see link:{qdrouterdConfManPageUrl}#_log[log] in the `qdrouterd.conf` man page.
---
-
-== Viewing Log Entries
-
-You may need to view log entries to diagnose errors, performance problems, and other important issues. A log entry consists of an optional timestamp, the logging module, the logging level, and the log message.
-
-=== Viewing Log Entries on the Console
-
-By default, log entries are logged to the console, and you can view them there. However, if the `output` attribute is set for a particular logging module, then you can find those log entries in the specified location (`stderr`, `syslog`, or a file).
-
-=== Viewing Log Entries on the CLI
-
-You can use the `qdstat` tool to view a list of recent log entries.
-
-.Procedure
-
-* Use the *`qdstat --log`* command to view recent log entries.
-+
---
-You can use the `--limit` parameter to limit the number of log entries that are displayed. For more information about `qdstat`, see {qdstatManPageLink}.
-
-This example displays the last three log entries for `Router.A`:
-
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat --log --limit=3 -r ROUTER.A
-Wed Jun 7 17:49:32 2017 ROUTER (none) Core action 'link_deliver'
-Wed Jun 7 17:49:32 2017 ROUTER (none) Core action 'send_to'
-Wed Jun 7 17:49:32 2017 SERVER (none) [2]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1, link-credit=250, drain=false]
-----
---
diff --git a/docs/books/modules/user-guide/managing-using-qdmanage.adoc b/docs/books/modules/user-guide/managing-using-qdmanage.adoc
index 9a68c68..879d5e9 100644
--- a/docs/books/modules/user-guide/managing-using-qdmanage.adoc
+++ b/docs/books/modules/user-guide/managing-using-qdmanage.adoc
@@ -17,32 +17,34 @@
under the License
////
-[id='managing-router']
-= Managing {RouterName} Using `qdmanage`
+// This assembly is included in the following assemblies:
+//
+// book.adoc
-You can use `qdmanage` to view and modify the configuration of a running router at runtime. Specifically, `qdmanage` enables you to create, read, update, and delete the sections and attributes in the router's configuration file without having to restart the router.
+[id='managing-using-qdmanage-{context}']
+= Managing using `qdmanage`
+
+The `qdmanage` tool is a command-line tool for viewing and modifying the configuration of a running router at runtime.
[NOTE]
====
-The `qdmanage` tool implements the AMQP management specification, which means that you can use it with any standard AMQP-managed endpoint, not just with {RouterName}.
+If you make a change to a router using `qdmanage`, the change takes effect immediately, but is lost if the router is stopped. If you want to make a permanent change to a router's configuration, you must edit the router's `{RouterConfigFile}` configuration file.
====
-== Syntax for Using `qdmanage`
-
You can use `qdmanage` with the following syntax:
[options="nowrap",subs="+quotes"]
----
-$ qdmanage [__CONNECTION_OPTIONS__] __OPERATION__ [__OPTIONS__]
+$ qdmanage [__<connection-options>__] __<operation>__ [__<options>__]
----
This specifies:
-* One or more optional `connection_options` to specify the router on which to perform the operation, or to supply security credentials if the router only accepts secure connections.
+* One or more optional _connection options_ to specify the router on which to perform the operation, or to supply security credentials if the router only accepts secure connections.
+
If you do not specify any connection options, `qdmanage` connects to the router listening on localhost and the default AMQP port (5672).
-* The `operation` to perform on the router.
-* One or more optional `options` to specify a configuration entity on which to perform the operation or how to format the command output.
+* The _operation_ to perform on the router.
+* One or more optional _options_ to specify a configuration entity on which to perform the operation or how to format the command output.
When you enter a `qdmanage` command, it is executed as an AMQP management operation request, and then the response is returned as command output in JSON format.
@@ -75,637 +77,6 @@
]
----
-For more information about `qdmanage`, see the {qdmanageManPageLink}.
+.Additional resources
-== Closing a connection
-
-If a consumer is processing messages too slowly, or has stopped processing messages without settling its deliveries, you can close the connection. When you close the connection, the "stuck" deliveries are released.
-
-.Procedure
-
-. Find the ID of the connection with the slow consumer.
-+
---
-This command lists the connections for a router in the router network:
-
-[options="nowrap"]
-----
-$ qdstat -c -r Router.A
-Connections
-id host container role dir security authentication tenant
-==================================================================================================================================
- 2 127.0.0.1:5672 route-container out no-security anonymous-user
- 10 127.0.0.1:5001 Router.B inter-router out no-security anonymous-user
- 12 localhost.localdomain:42972 161211fe-ba9e-4726-9996-52d6962d1276 normal in no-security anonymous-user
- 14 localhost.localdomain:42980 a35fcc78-63d9-4bed-b57c-053969c38fda normal in no-security anonymous-user
- 15 localhost.localdomain:42982 0a03aa5b-7c45-4500-8b38-db81d01ce651 normal in no-security anonymous-user
-----
---
-
-. Close the connection by setting its `adminStatus` to `deleted`.
-+
-[options="nowrap"]
-----
-$ qdmanage update --type=connection --id=12 adminStatus=deleted
-----
-
-== Managing Network Connections
-
-You can use `qdmanage` to view, create, update, and delete listeners and connectors for any router in your router network.
-
-=== Managing Listeners
-
-Listeners define how clients can connect to a router. The following table lists the `qdmanage` commands you can use to perform common operations on listeners.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page.
-
-//tag::qdmanage-connection-options-note[]
-[NOTE]
-====
-The commands in this table demonstrate operations on the local router listening on localhost and the default AMQP port (5672). If you want to perform an operation on a different router in the router network, you must specify the necessary connection options. For more information, see link:{qdmanageManPageUrl}#_connection_options[Connection Options] in the qdmanage man page.
-====
-//end::qdmanage-connection-options-note[]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View the router’s listeners
-a|
-[options="nowrap"]
-----
-qdmanage query --type=listener
-----
-
-|View the roles and ports on which the router is listening
-a|
-[options="nowrap"]
-----
-qdmanage query role port --type=listener
-----
-
-|View the attributes configured for a listener
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage read --name=_LISTENER_NAME_
-----
-
-|Create a listener
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --type=listener --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Create multiple listeners
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage create --stdin
-----
-. Configure the listeners using a JSON map:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}...]
-----
-
-These commands use a JSON map to create two listeners.
-
-|Update a listener
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=listener --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Update multiple listeners
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage update --stdin
-----
-. Configure the listeners using a JSON map:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="listener", "_ATTRIBUTE_":"_VALUE_"...}...]
-----
-
-These commands use a JSON map to update two listeners.
-
-|Delete an attribute from a listener
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=listener --_ATTRIBUTE_
-----
-
-|Delete a listener
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_LISTENER_NAME_
-----
-
-|===
-
-[id='managing-connectors']
-=== Managing Connectors
-
-Connectors define how the router can connect to other endpoints in your messaging network, such as brokers and other routers. The following table lists the `qdmanage` commands you can use to perform common operations on connectors.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View the router’s connectors
-a|
-[options="nowrap"]
-----
-qdmanage query --type=connector
-----
-
-|View the roles and ports on which the router can connect to other endpoints
-a|
-[options="nowrap"]
-----
-qdmanage query role port --type=connector
-----
-
-|If the router is connected to a broker, view the alternate URLs on which the router can connect to the broker if the primary connection fails
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage query failoverUrls --type=connector --name=CONNECTOR_NAME
-----
-
-|View the attributes configured for a connector
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage read --name=_CONNECTOR_NAME_
-----
-
-|Create a connector
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --type=connector --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Create multiple connectors
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage create --stdin
-----
-. Configure the connectors using a JSON map:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}...]
-----
-
-These commands use a JSON map to create two connectors.
-
-|Update a connector
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=connector --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Update multiple connectors
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage update --stdin
-----
-. Configure the connectors using a JSON map:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}, {"type"="connector", "_ATTRIBUTE_":"_VALUE_"...}...]
-----
-
-These commands use a JSON map to update two connectors.
-
-|Delete an attribute from a connector
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=connector --_ATTRIBUTE_
-----
-
-|Delete a connector
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_CONNECTOR_NAME_
-----
-
-|===
-
-== Managing Security
-
-{RouterName} supports both SSL/TLS and SASL security protocols for encrypting and authenticating incoming and outgoing connections for your routers. You can use `qdmanage` to view, create, update, and delete security policies for any router in your router network.
-
-=== Managing SSL/TLS Encryption and Authentication
-
-{RouterName} supports SSL/TLS for certificate-level encryption and mutual authentication. The following table lists the common `qdmanage` commands you can use to secure incoming and outgoing connections for a router in your router network.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_sslprofile[sslProfile] and link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View the router’s SSL/TLS configuration
-a|
-[options="nowrap"]
-----
-qdmanage query --type=sslProfile
-----
-
-|Set up SSL/TLS for the router
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --type=sslProfile --name=_NAME_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Add SSL/TLS encryption to an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --sslProfile=_NAME_ --requireSsl=yes
-----
-
-|Change SSL/TLS encryption on an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Add SSL/TLS client authentication to an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --authenticatePeer=yes
-----
-
-|Remove SSL/TLS client authentication from an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --authenticatePeer=no
-----
-
-|Add SSL/TLS client authentication to an outgoing connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_CONNECTOR_NAME_ --sslProfile=_NAME_
-----
-
-|Remove SSL/TLS client authentication from an outgoing connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_CONNECTOR_NAME_ --sslProfile
-----
-
-|Delete an SSL profile
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_SSL_PROFILE_NAME_
-----
-
-|===
-
-=== Managing SASL Encryption and Authentication
-
-{RouterName} supports SASL for authentication and payload encryption. The following table lists the common `qdmanage` commands you can use to secure incoming and outgoing connections for a router in your router network.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_router[router] and link:{qdrouterdConfManPageUrl}#_listener[listener] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|Set up SASL for the router
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=router --saslConfigDir=_PATH_ --saslConfigName=_NAME_
-----
-
-|Add SASL authentication to an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --authenticatePeer=yes --saslMechanisms=_MECHANISMS_
-----
-
-|Change SASL mechanisms for an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --saslMechanisms=_MECHANISMS_
-----
-
-|Add SASL authentication to an outgoing connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_CONNECTOR_NAME_ --saslMechanisms=_MECHANISMS_ --saslUsername=_USERNAME_ --saslPassword=_PASSWORD_
-----
-
-|Change SASL mechanisms for an outgoing connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_CONNECTOR_NAME_ --saslMechanisms=_MECHANISMS_
-----
-
-|Add SASL payload encryption to an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --requireEncryption=yes --saslMechanisms=_MECHANISMS_
-----
-
-|Change SASL mechanisms for an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --saslMechanisms=_MECHANISMS_
-----
-
-|Remove SASL payload encryption from an incoming connection
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LISTENER_NAME_ --requireEncryption=no --saslMechanisms
-----
-
-|Delete a SASL configuration
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=router --saslConfigDir --saslConfigName
-----
-
-|===
-
-== Managing Routing
-
-{RouterName} supports both message routing and link routing for distributing messages between senders and receivers. You can use `qdmanage` to view how addresses and link routes are configured in your environment, and define how a router should distribute messages.
-
-=== Managing Message Routing
-
-Message routing involves configuring addresses to define how {RouterName} should distribute messages. The following table lists the common `qdmanage` commands you can use to configure addresses for a router in your router network.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_address[address] and link:{qdrouterdConfManPageUrl}#_autolink[autolink] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View addresses
-a|
-[options="nowrap"]
-----
-qdmanage query --type=address
-----
-
-[options="nowrap",subs="+quotes"]
-----
-qdmanage read --name=_ADDRESS_NAME_
-----
-
-|View address distribution patterns
-a|
-[options="nowrap"]
-----
-qdmanage query prefix distribution --type=address
-----
-
-|View waypoints to broker queues
-a|
-[options="nowrap"]
-----
-qdmanage query prefix --type=address --waypoint=yes
-----
-
-|View autolinks
-a|
-[options="nowrap"]
-----
-qdmanage query --type=autolink
-----
-
-|Set a distribution pattern for an address
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --type=address --prefix=_ADDRESS_PREFIX_ --distribution=_DISTRIBUTION_PATTERN_ ...
-----
-
-|Set distribution patterns for multiple addresses
-a|
-. Enter this command:
-+
-[options="nowrap",subs="+quotes"]
-----
-qdmanage create --stdin
-----
-
-. Configure the addresses using a JSON map:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type":"address", "prefix":"_ADDRESS_PREFIX_", "distribution":"_DISTRIBUTION_PATTERN_", "_ATTRIBUTE_":"_VALUE_", ...}, {"type":"address", "prefix":"_ADDRESS_PREFIX_", "distribution":"_DISTRIBUTION_PATTERN_", "_ATTRIBUTE_":"_VALUE_", ...} ...]
-----
-
-These commands configure two addresses.
-
-|Connect an address to a broker queue
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage create --stdin
-----
-
-. Create an address waypoint, an incoming autolink, and an outgoing autolink:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type":"address", "prefix":"_ADDRESS_PREFIX_", "waypoint":"yes"}, {"type":"autolink", "addr":"_ADDRESS_NAME_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"in"}, {"type":"autolink", "addr":"_ADDRESS_NAME_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"out"}]
-----
-
-|Update an address configuration
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_ADDRESS_NAME_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Update an autolink
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_AUTOLINK_NAME_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Delete an address configuration
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_ADDRESS_NAME_
-----
-
-|Delete an autolink
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_AUTOLINK_NAME_
-----
-
-|===
-
-=== Managing Link Routing
-
-A link route is a chain of links between a sender and receiver that provides a private messaging path. The following table lists the common `qdmanage` commands you can use to view, create, update, and delete link routes.
-
-For more information about the attributes you can use with these commands, see the link:{qdrouterdConfManPageUrl}#_linkroute[linkRoute] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View link routes
-a|
-[options="nowrap"]
-----
-qdmanage query --type=linkRoute
-----
-
-[options="nowrap",subs="+quotes"]
-----
-qdmanage read --name=_LINK_ROUTE_NAME_
-----
-
-|Create a link route
-a|
-. Enter this command:
-+
-[options="nowrap"]
-----
-qdmanage create --stdin
-----
-
-. Create an incoming and outgoing link route:
-+
-[options="nowrap",subs="+quotes"]
-----
-[{"type":"linkRoute", "prefix":"_ADDRESS_PREFIX_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"in", ...}, {"type":"linkRoute", "prefix":"_ADDRESS_PREFIX_", "connection":"_CONNECTOR/LISTENER_NAME_", "direction":"out", ...}]
-----
-
-|Update a link route
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --name=_LINK_ROUTE_NAME_ --_ATTRIBUTE_=_VALUE_ ...
-----
-
-|Delete a link route
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage delete --name=_INCOMING_LINK_ROUTE_NAME_
-qdmanage delete --name=_OUTGOING_LINK_ROUTE_NAME_
-----
-
-|===
-
-== Managing Logging
-
-{RouterName} logs are broken into different categories called logging modules. Each module provides important information about a particular aspect of a router. The following table lists the common `qdmanage` commands you can use to view and change the configuration of a logging module.
-
-For more information about the attributes you can use with these commands, see link:{qdrouterdConfManPageUrl}#_log[log] in the `qdrouterd.conf` man page.
-
-// Note about qdmanage connection options.
-include::managing-using-qdmanage.adoc[tags=qdmanage-connection-options-note]
-
-[cols="30,70"]
-|===
-| To... | Use this command...
-
-|View the logging configuration
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage query --type=log
-----
-
-|View the logging configuration for a logging module
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage read --type=log --name=log/_LOGGING_MODULE_NAME_
-----
-
-|Set the default logging configuration
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=log --name=log/DEFAULT enable=_LOGGING_LEVEL_ includeTimestamp=yes _ATTRIBUTE_=_VALUE_
-----
-
-|Enable logging for a logging module
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=log --name=log/_LOGGING_MODULE_NAME_ enable=_LOGGING_LEVEL_ _ATTRIBUTE_=_VALUE_ ...
-----
-
-|Change the logging configuration for a logging module
-a|
-[options="nowrap",subs="+quotes"]
-----
-qdmanage update --type=log --name=log/_LOGGING_MODULE_NAME_ _ATTRIBUTE_=_VALUE_ ...
-----
-
-|===
+* For more information about `qdmanage`, see the {qdmanageManPageLink}.
diff --git a/docs/books/modules/user-guide/message-routing-flow-control.adoc b/docs/books/modules/user-guide/message-routing-flow-control.adoc
new file mode 100644
index 0000000..88b2007
--- /dev/null
+++ b/docs/books/modules/user-guide/message-routing-flow-control.adoc
@@ -0,0 +1,31 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// understanding-message-routing.adoc
+
+[id='message-routing-flow-control-{context}']
+= Message routing flow control
+
+{RouterName} uses a _credit-based_ flow control mechanism to ensure that producers can only send messages to a router if at least one consumer is available to receive them. Because {RouterName} does not store messages, this credit-based flow control prevents producers from sending messages when there are no consumers present.
+
+A client wishing to send a message to the router must wait until the router has provided it with credit. Attempting to publish a message without credit available will cause the client to block. Once credit is made available, the client will unblock, and the message will be sent to the router.
+
+NOTE: Most AMQP client libraries enable you to determine the amount of credit available to a producer. For more information, consult your client's documentation.
diff --git a/docs/books/modules/user-guide/message-settlement-reliability-message-routing.adoc b/docs/books/modules/user-guide/message-settlement-reliability-message-routing.adoc
new file mode 100644
index 0000000..f78b3d5
--- /dev/null
+++ b/docs/books/modules/user-guide/message-settlement-reliability-message-routing.adoc
@@ -0,0 +1,69 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// understanding-message-routing.adoc
+
+[id='message-settlement-reliability-message-routing-{context}']
+= Message settlement and reliability
+
+{RouterName} can deliver messages with the following degrees of reliability:
+
+* At most once
+* At least once
+* Exactly once
+
+The level of reliability is negotiated between the producer and the router when the producer establishes a link to the router. To achieve the negotiated level of reliability, {RouterName} treats all messages as either _pre-settled_ or _unsettled_.
+
+Pre-settled::
+Sometimes called _fire and forget_, the router settles the incoming and outgoing deliveries and propagates the settlement to the message's destination. However, it does not guarantee delivery.
+
+Unsettled::
+{RouterName} propagates the settlement between the producer and consumer. For an anycast address, the router associates the incoming delivery with the resulting outgoing delivery. Based on this association, the router propagates changes in delivery state from the consumer to the producer.
++
+For a multicast address, the router associates the incoming delivery with all outbound deliveries. The router waits for each consumer to set their delivery's final state. After all outgoing deliveries have reached their final state, the router sets a final delivery state for the original inbound delivery and passes it to the producer.
++
+The following table describes the reliability guarantees for unsettled messages sent to an anycast or multicast address:
++
+[cols="20,40,40"]
+|===
+| Final disposition | Anycast | Multicast
+
+| `accepted`
+| The consumer received the message.
+a|
+Either:
+
+* All consumers received the message,
+
+* Or, at least one consumer received the message, but no consumers rejected it.
+
+| `released`
+| The message did not reach its destination.
+| The message did not reach any of the consumers.
+
+| `modified`
+| The message may or may not have reached its destination. The delivery is considered to be "in-doubt" and should be re-sent if "at least once" delivery is required.
+| The message may or may not have reached any of the consumers. However, no consumers rejected or accepted it.
+
+| `rejected`
+| The consumer rejected the message.
+| At least one consumer rejected the message.
+|===
diff --git a/docs/books/modules/user-guide/methods-specifying-vhost-policy-source-target-addresses.adoc b/docs/books/modules/user-guide/methods-specifying-vhost-policy-source-target-addresses.adoc
new file mode 100644
index 0000000..d2580cc
--- /dev/null
+++ b/docs/books/modules/user-guide/methods-specifying-vhost-policy-source-target-addresses.adoc
@@ -0,0 +1,96 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// setting-connection-resource-limits-messaging-endpoints.adoc
+
+[id='methods-specifying-vhost-policy-source-target-addresses-{context}']
+= Methods for specifying vhost policy source and target addresses
+
+If you want to allow or deny access to multiple addresses on a vhost, there are several methods you can use to match multiple addresses without having to specify each address individually.
+
+The following table describes the methods a vhost policy can use to specify multiple source and target addresses:
+
+[cols="33,67",options="header"]
+|===
+| To... | Do this...
+
+| Allow all users in the user group to access all source or target addresses
+a| Use a `*` wildcard character.
+
+.Receive from any address
+====
+[source,options="nowrap"]
+----
+sources: *
+----
+====
+
+| Prevent all users in the user group from accessing all source or target addresses
+a| Do not specify a value.
+
+.Prohibit message transfers to all addresses
+====
+[source,options="nowrap"]
+----
+targets:
+----
+====
+
+| Allow access to some resources specific to each user
+a| Use the `${user}` username substitution token. You can use this token with `source`, `target`, `sourcePattern`, and `targetPattern`.
+
+[NOTE]
+====
+You can only specify the `${user}` token once in an AMQP address name or pattern. If there are multiple tokens in an address, only the leftmost token will be substituted.
+====
+
+.Receive from a user-specific address
+====
+This definition allows the users in the user group to receive messages from any address that meets any of the following rules:
+
+* Starts with the prefix `tmp_` and ends with the user name
+* Starts with the prefix `temp` followed by any additional characters
+* Starts with the user name, is followed by `-home-`, and ends with any additional characters
+[source,options="nowrap"]
+----
+sources: tmp_${user}, temp*, ${user}-home-*
+----
+====
+
+.User-specific address patterns
+====
+This definition allows the users in the user group to receive messages from any address that meets any of the following rules:
+
+* Starts with the prefix `tmp` and ends with the user name
+* Starts with the prefix `temp` followed by zero or more additional characters
+* Starts with the user name, is followed by `home`, and ends with one or more additional characters
+[source,options="nowrap"]
+----
+sourcePattern: tmp.${user}, temp/#, ${user}.home/*
+----
+====
+
+[NOTE]
+====
+In an address pattern (`sourcePattern` or `targetPattern`), the username substitution token must be either the first or last token in the pattern. The token must also be alone within its delimited field, which means that it cannot be concatenated with literal text prefixes or suffixes.
+====
+
+|===
diff --git a/docs/books/modules/user-guide/monitoring-router-network-web-console.adoc b/docs/books/modules/user-guide/monitoring-router-network-web-console.adoc
new file mode 100644
index 0000000..50f2479
--- /dev/null
+++ b/docs/books/modules/user-guide/monitoring-router-network-web-console.adoc
@@ -0,0 +1,45 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// monitoring-using-web-console.adoc
+
+[id='monitoring-router-network-web-console'-{context}']
+= Monitoring the router network using {ConsoleName}
+
+In the web console, you use the tabs to monitor the router network.
+
+[cols="30,70"]
+|===
+| This tab... | Provides...
+
+| `Overview` | Aggregated information about routers, addresses, links, connections, and logs.
+
+| `Entities` | Detailed information about each AMQP management entity for each router in the router network. Some of the attributes have charts that you can add to the `Charts` tab.
+
+| `Topology` | A graphical view of the router network, including routers, clients, and brokers. The topology shows how the routers are connected, and how messages are flowing through the network.
+
+| `Charts` | Graphs of the information selected on the `Entities` tab.
+
+| `Message Flow` | A chord diagram showing the real-time message flow by address.
+
+| `Schema` | The management schema that controls each of the routers in the router network.
+
+|===
diff --git a/docs/books/modules/user-guide/monitoring-using-qdstat.adoc b/docs/books/modules/user-guide/monitoring-using-qdstat.adoc
deleted file mode 100644
index 77b065a..0000000
--- a/docs/books/modules/user-guide/monitoring-using-qdstat.adoc
+++ /dev/null
@@ -1,452 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License
-////
-
-[id='monitoring-using-qdstat']
-= Monitoring {RouterName} Using `qdstat`
-
-You can use `qdstat` to view the status of routers on your router network. For example, you can view information about the attached links and configured addresses, available connections, and nodes in the router network.
-
-== Syntax for Using `qdstat`
-
-You can use `qdstat` with the following syntax:
-
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat __OPTION__ [__CONNECTION_OPTIONS__] [__SECURE_CONNECTION_OPTIONS__]
-----
-
-This specifies:
-
-* An `option` for the type of information to view.
-* One or more optional `connection_options` to specify a router for which to view the information.
-+
-If you do not specify a connection option, `qdstat` connects to the router listening on localhost and the default AMQP port (5672).
-* The `secure_connection_options` if the router for which you want to view information only accepts secure connections.
-
-For more information about `qdstat`, see the {qdstatManPageLink}.
-
-== Creating a State Dump of the Router Network
-
-A state dump shows the current operational state of the router network. You can display the following statistics for a single router, or for all routers in the router network:
-
-* Links
-* Addresses
-* Connections
-* Autolinks
-* Link routes
-* General statistics
-* Memory usage
-
-.Procedure
-
-* Do one of the following:
-+
---
-[cols="30,70"]
-|===
-| To... | Use this command:
-
-| Create a state dump containing all statistics for all routers
-a|
-[options="nowrap"]
-----
-$ qdstat --all-routers --all-entities
-----
-
-If you run this command on an interior router, it displays the statistics for all interior routers. If you run the command on an edge router, it displays the statistics for only that edge router.
-
-| Create a state dump containing a single statistic for all routers
-a|
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -l\|-a\|-c\|--autolinks\|--linkroutes\|-g\|-m --all-routers
-----
-
-If you run this command on an interior router, it displays the statistic for all interior routers. If you run the command on an edge router, it displays the statistic for only that edge router.
-
-| Create a state dump containing all statistics for a single router
-a|
-[options="nowrap"]
-----
-$ qdstat --all-entities
-----
-
-This command shows the statistics for the local router only.
-|===
---
-
-== Viewing General Statistics for a Router
-
-You can view information about a router in the router network, such as its working mode and ID.
-
-.Procedure
-
-* Use the following command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -g [all-routers|__CONNECTION_OPTIONS__]
-----
-
-This example shows general statistics for the local router:
-
-[options="nowrap"]
-----
-$ qdstat -g
-Router Statistics
- attr value
- =============================================
- Version 1.2.0
- Mode standalone
- Router Id Router.A
- Link Routes 0
- Auto Links 0
- Links 2
- Nodes 0
- Addresses 4
- Connections 1
- Presettled Count 0
- Dropped Presettled Count 0
- Accepted Count 2
- Rejected Count 0
- Released Count 0
- Modified Count 0
- Ingress Count 2
- Egress Count 1
- Transit Count 0
- Deliveries from Route Container 0
- Deliveries to Route Container 0
-----
---
-
-== Viewing a List of Connections to a Router
-
-You can view:
-
-* Connections from clients (sender/receiver)
-* Connections from and to other routers in the network
-* Connections to other containers (such as brokers)
-* Connections from the tool itself
-
-.Procedure
-
-* Use this command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -c [all-routers|__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_c[the qdstat -c output columns^].
-
-In this example, two clients are connected to `Router.A`. `Router.A` is connected to `Router.B` and a broker.
-
-Viewing the connections on Router.A displays the following:
-
-[options="nowrap"]
-----
-$ qdstat -c -r Router.A
-Connections
-id host container role dir security authentication tenant
-==================================================================================================================================
- 2 127.0.0.1:5672 route-container out no-security anonymous-user // <1>
- 10 127.0.0.1:5001 Router.B inter-router out no-security anonymous-user // <2>
- 12 localhost.localdomain:42972 161211fe-ba9e-4726-9996-52d6962d1276 normal in no-security anonymous-user // <3>
- 14 localhost.localdomain:42980 a35fcc78-63d9-4bed-b57c-053969c38fda normal in no-security anonymous-user // <3>
- 15 localhost.localdomain:42982 0a03aa5b-7c45-4500-8b38-db81d01ce651 normal in no-security anonymous-user // <4>
-----
-<1> This connection shows that `Router.A` is connected to a broker, because the `role` is `route-container`, and the `dir` is `out`.
-<2> `Router.A` is also connected to another router on the network (the `role` is `inter-router`), establishing an output connection (the `dir` is `out`).
-<3> These connections show that two clients are connected to `Router.A`, because the `role` is `normal`, and the `dir` is `in`.
-<4> The connection from `qdstat` to `Router.A`. This is the connection that `qdstat` uses to query `Router.A` and display the command output.
-
-`Router.A` is connected to `Router.B`. Viewing the connections on `Router.B` displays the following:
-
-[options="nowrap"]
-----
-$ qdstat -c -r Router.B
-Connections
-id host container role dir security authentication tenant
-====================================================================================================
- 1 localhost.localdomain:51848 Router.A inter-router in no-security anonymous-user // <1>
-----
-<1> This connection shows that `Router.B` is connected to `Router.A` through an incoming connection (the `role` is `inter-router` and the `dir` is `in`). There is not a connection from `qdstat` to `Router.B`, because the command was run from `Router.A` and forwarded to `Router.B`.
---
-
-== Viewing AMQP Links Attached to a Router
-
-You can view a list of AMQP links attached to the router from clients (sender/receiver), from or to other routers into the network, to other containers (for example, brokers), and from the tool itself.
-
-.Procedure
-* Use this command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -l [all-routers|__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_l[the qdstat -l output columns^].
-
-In this example, `Router.A` is connected to both `Router.B` and a broker. A link route is configured for the `my_queue` queue and waypoint (with autolinks), and for the `my_queue_wp` queue on the broker. In addition, there is a receiver connected to `my_address` (message routing based), another to `my_queue`, and the a third one to `my_queue_wp`.
-
-In this configuration, the router uses only one connection to the broker for both the waypoints (related to `my_queue_wp`) and the link route (related to `my_queue`).
-
-Viewing the links displays the following:
-
-[options="nowrap"]
-----
-$ qdstat -l
-Router Links
- type dir conn id id peer class addr phs cap undel unsett del presett psdrop acc rej rel mod admin oper
- ======================================================================================================================================================
- router-control in 2 7 250 0 0 2876 0 0 0 0 0 0 enabled up // <1>
- router-control out 2 8 local qdhello 250 0 0 2716 0 0 0 0 0 0 enabled up
- inter-router in 2 9 250 0 0 1 0 0 0 0 0 0 enabled up
- inter-router out 2 10 250 0 0 1 0 0 0 0 0 0 enabled up
- endpoint in 1 11 mobile my_queue_wp 1 250 0 0 3 0 0 0 0 0 0 enabled up // <2>
- endpoint out 1 12 mobile my_queue_wp 0 250 0 0 3 0 0 0 0 0 0 enabled up
- endpoint out 4 15 mobile my_address 0 250 0 0 0 0 0 0 0 0 0 enabled up // <3>
- endpoint out 6 18 19 250 0 0 1 0 0 0 0 0 0 enabled up // <4>
- endpoint in 1 19 18 0 0 0 1 0 0 0 0 0 0 enabled up // <5>
- endpoint out 19 40 mobile my_queue_wp 1 250 0 0 1 0 0 0 0 0 0 enabled up // <6>
- endpoint in 24 48 mobile $management 0 250 0 0 1 0 0 0 0 0 0 enabled up
- endpoint out 24 49 local temp.mx5HxzUe2Eddw_s 250 0 0 0 0 0 0 0 0 0 enabled up
-----
-<1> The `conn id` 2 connection has four links (in both directions) for inter-router communications with `Router.B`, such as control messages and normal message-routed deliveries.
-<2> There are two autolinks (`conn id 1`) for the waypoint for `my_queue_wp`. There is an incoming (`id 11`) and outgoing (`id 12`) link to the broker, and another `out` link (`id 40`) to the receiver.
-<3> A `mobile` link for `my_address`. The `dir` is `out` related to the receiver attached to it.
-<4> The `out` link from the router to the receiver for `my_queue`. This enables the router to deliver messages to the receiver.
-<5> The `in` link to the router for `my_queue`. This enables the router to get messages from `my_queue` so that they can be sent to the receiver on the `out` link.
-<6> The remaining links are related to the `$management` address and are used by `qdstat` to receive the information that is displayed by this command.
---
-
-== Viewing Known Routers on a Network
-
-To see the topology of the router network, you can view known routers on the network.
-
-.Procedure
-
-* Use this command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -n [all-routers|__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_n[the qdstat -n output columns^].
-
-In this example, `Router.A` is connected to `Router.B`, which is connected to `Router.C`. Viewing the router topology on `Router.A` shows the following:
-
-[options="nowrap"]
-----
-$ qdstat -n -r Router.A
-Routers in the Network
- router-id next-hop link cost neighbors valid-origins
- ==========================================================================
- Router.A (self) - ['Router.B'] [] // <1>
- Router.B - 0 1 ['Router.A', 'Router.C'] [] // <2>
- Router.C Router.B - 2 ['Router.B'] [] // <3>
-----
-<1> `Router.A` has one neighbor: `Router.B`.
-<2> `Router.B` is connected to `Router.A` and `Router.C` over `link` 0. The `cost` for `Router.A` to reach `Router.B` is 1, because the two routers are connected directly.
-<3> `Router.C` is connected to `Router.B`, but not to `Router.A`. The `cost` for `Router.A` to reach `Router.C` is 2, because messages would have to pass through `Router.B` as the `next-hop`.
-
-`Router.B` shows a different view of the router topology:
-
-[options="nowrap"]
-----
-$ qdstat -n -v -r Router.B
-Routers in the Network
- router-id next-hop link cost neighbors valid-origins
- ==========================================================================
- Router.A - 0 1 ['Router.B'] ['Router.C']
- Router.B (self) - ['Router.A', 'Router.C'] []
- Router.C - 1 1 ['Router.B'] ['Router.A']
-----
-
-The `neighbors` list is the same when viewed on `Router.B`. However, from the perspective of `Router.B`, the destinations on `Router.A` and `Router.C` both have a `cost` of `1`. This is because `Router.B` is connected to `Router.A` and `Router.C` through links.
-
-The `valid-origins` column shows that starting from `Router.C`, `Router.B` has the best path to reach `Router.A`. Likewise, starting from `Router.A`, `Router.B` has the best path to reach `Router.C`.
-
-Finally, `Router.C` shows the following details about the router topology:
-
-[options="nowrap"]
-----
-$ qdstat -n -v -r Router.C
-Routers in the Network
- router-id next-hop link cost neighbors valid-origins
- ==========================================================================
- Router.A Router.B - 2 ['Router.B'] []
- Router.B - 0 1 ['Router.A', 'Router.C'] []
- Router.C (self) - ['Router.B'] []
-----
-
-Due to a symmetric topology, the `Router.C` perspective of the topology is very similar to the `Router.A` perspective. The primary difference is the `cost`: the cost to reach `Router.B` is `1`, because the two routers are connected. However, the cost to reach `Router.A` is `2`, because the messages would have to pass through `Router.B` as the `next-hop`.
---
-
-== Viewing Addresses Known to a Router
-
-You can view message-routed and link-routed addresses known to a router.
-
-.Procedure
-
-* Use the following command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -a [all-routers|__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_a[the qdstat -a output columns^].
-
-In this example, `Router.A` is connected to both `Router.B` and a broker. The broker has two queues:
-
-* `my_queue` (with a link route on `Router.A`)
-* `my_queue_wp` (with a waypoint and autolinks configured on `Router.A`)
-
-In addition, there are three receivers: one connected to `my_address` for message routing, another connected to `my_queue`, and the last one connected to `my_queue_wp`.
-
-Viewing the addresses displays the following information:
-
-[options="nowrap"]
-----
-$ qdstat -a
-Router Addresses
- class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
- ======================================================================================================================
- local $_management_internal closest 1 0 0 0 0 0 0 0 0
- local $displayname closest 1 0 0 0 0 0 0 0 0
- mobile $management 0 closest 1 0 0 0 8 0 0 8 0
- local $management closest 1 0 0 0 0 0 0 0 0
- router Router.B closest 0 0 1 0 0 0 5 0 5 // <1>
- mobile my_address 0 closest 0 1 0 0 1 1 0 0 0 // <2>
- link-in my_queue linkBalanced 0 0 0 1 0 0 0 0 0 // <3>
- link-out my_queue linkBalanced 0 0 0 1 0 0 0 0 0
- mobile my_queue_wp 1 balanced 0 1 0 0 1 1 0 0 0 // <4>
- mobile my_queue_wp 0 balanced 0 1 0 0 1 1 0 0 0
- local qdhello flood 1 1 0 0 0 0 0 741 706 // <5>
- local qdrouter flood 1 0 0 0 0 0 0 4 0
- topo qdrouter flood 1 0 1 0 0 0 27 28 28
- local qdrouter.ma multicast 1 0 0 0 0 0 0 1 0
- topo qdrouter.ma multicast 1 0 1 0 0 0 2 0 3
- local temp.IJSoXoY_lX0TiDE closest 0 1 0 0 0 0 0 0 0
-----
-<1> An address related to `Router.B` with a `remote` at 1. This is the consumer from `Router.B`.
-<2> The `my_address` address has one local consumer, which is related to the single receiver attached on that address. The `in` and `out` fields are both 1, which means that one message has traveled through this address using the `closest` distribution method.
-<3> The incoming link route for the `my_queue` address. This address has one locally-attached container (`cntnr`) as a destination (in this case, the broker). The following entry is the outgoing link for the same address.
-<4> The incoming autolink for the `my_queue_wp` address and configured waypoint. There is one local consumer (`local`) for the attached receiver. The following entry is the outgoing autolink for the same address. A single message has traveled through the autolinks.
-<5> The `qdhello`, `qdrouter`, and `qdrouter.ma` addresses are used to periodically update the network topology and deliver router control messages. These updates are made automatically through the inter-router protocol, and are based on all of the messages the routers have exchanged. In this case, the distribution method (`distrib`) for each address is either flood or multicast to ensure the control messages reach all of the routers in the network.
---
-
-== Viewing a Router's Autolinks
-
-You can view a list of the autolinks that are associated with waypoint addresses for a node on another container (such as a broker).
-
-.Procedure
-
-* Use the following command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat --autolinks [all-routers|__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_autolinks[the qdstat --autolinks output columns^].
-
-In this example, a router is connected to a broker. The broker has a queue called `my_queue_wp`, to which the router is configured with a waypoint and autolinks. Viewing the autolinks displays the following:
-
-[options="nowrap"]
-----
-$ qdstat --autolinks
-AutoLinks
- addr dir phs link status lastErr
- ==============================================
- my_queue_wp in 1 4 active // <1>
- my_queue_wp out 0 5 active // <2>
-----
-<1> The incoming autolink from `my_queue_wp`. As indicated by the `status` field, the link is active, because the broker is running and the connection for the link is already established (as indicated by the `link` field).
-<2> The outgoing autolink to `my_queue_wp`. Like the incoming link, it is active and has an established connection.
---
-
-== Viewing the Status of a Router's Link Routes
-
-You can view the status of each incoming and outgoing link route.
-
-.Procedure
-
-* Use the following command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat --linkroutes [all-routers|__CONNECTION_OPTIONS__]
-----
-
-For more information about the fields displayed by this command, see link:{qdstatManPageUrl}#_qdstat_linkroutes[the qdstat --linkroutes output columns^].
-
-In this example, a router is connected to a broker. The router is configured with a link route to the `my_queue` queue on the broker. Viewing the link routes displays the following:
-
-[options="nowrap"]
-----
-$ qdstat --linkroutes
-Link Routes
- prefix dir distrib status
- =====================================
- my_queue in linkBalanced active // <1>
- my_queue out linkBalanced active // <2>
-----
-<1> The incoming link route from `my_queue` to the router. This route is currently active, because the broker is running.
-<2> The outgoing link from the router to `my_queue`. This route is also currently active.
---
-
-== Viewing Memory Consumption Information
-
-If you need to perform debugging or tracing for a router, you can view information about its memory consumption.
-
-.Procedure
-
-* Use the following command:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-$ qdstat -m [all-routers|__CONNECTION_OPTIONS__]
-----
-
-This command displays information about allocated objects, their size, and their usage by application threads:
-
-[options="nowrap"]
-----
-$ qdstat -m
-Types
- type size batch thread-max total in-threads rebal-in rebal-out
- ===========================================================================================
- qd_bitmask_t 24 64 128 64 64 0 0
- qd_buffer_t 536 16 32 80 80 0 0
- qd_composed_field_t 64 64 128 256 256 0 0
- qd_composite_t 112 64 128 320 320 0 0
- ...
-----
---
diff --git a/docs/books/modules/user-guide/next-steps.adoc b/docs/books/modules/user-guide/next-steps.adoc
index da96103..19fc358 100644
--- a/docs/books/modules/user-guide/next-steps.adoc
+++ b/docs/books/modules/user-guide/next-steps.adoc
@@ -26,11 +26,11 @@
After using {RouterName} to distribute messages between two clients, you can use the following sections to learn more about {RouterName} configuration, deployment, and management.
-xref:configuring-router-{context}[Configure non-default settings for the router]::
-{RouterName} ships with default settings that are suitable for many basic use cases. You can configure the router's essential properties, network connections, security settings, logging, and routing mechanisms.
+xref:configuration[Change the router's configuration]::
+{RouterName} ships with default settings that are suitable for many basic use cases. You can further experiment with the standalone router that you used in the _Getting started_ example by changing the router's essential properties, network connections, security settings, logging, and routing mechanisms.
-xref:creating-router-network-topology-{context}[Plan a {RouterName} deployment]::
+xref:installing-router-{context}[Install and configure {RouterName}]::
{RouterName} is typically deployed in router networks. You can design a router network of any arbitrary topology to interconnect the endpoints in your messaging network.
-xref:monitoring-managing-router-network[Monitor and manage {RouterName}]::
+xref:management[Monitor and manage {RouterName}]::
You can use the web console and command-line management tools to monitor the status and performance of the routers in your router network.
diff --git a/docs/books/modules/user-guide/router-deployment-workflow.adoc b/docs/books/modules/user-guide/preparing-router-configurations.adoc
similarity index 82%
rename from docs/books/modules/user-guide/router-deployment-workflow.adoc
rename to docs/books/modules/user-guide/preparing-router-configurations.adoc
index e639510..dcf9f6e 100644
--- a/docs/books/modules/user-guide/router-deployment-workflow.adoc
+++ b/docs/books/modules/user-guide/preparing-router-configurations.adoc
@@ -17,14 +17,14 @@
under the License
////
-// This assembly is included in the following assemblies:
+// This module is included in the following assemblies:
//
-// creating-router-network-topology.adoc
+// installing-router.adoc
-[id='router-deployment-workflow-{context}']
-= {RouterName} deployment workflow
+[id='preparing-router-configurations-{context}']
+= Preparing router configurations
-This workflow describes the basic workflow for deploying a {RouterName} router. To create a router network, complete this workflow for each router in the network.
+After installing {RouterName}, configure it to define how it should connect to other routers and endpoints, and how it should operate. If you are creating a router network, complete this workflow for each router in the network.
.Prerequisites
@@ -52,18 +52,16 @@
+
These properties should be configured the same way on each router. Therefore, you should only configure each one once, and then copy the configuration to each additional router in the router network.
-** xref:authorizing-access-to-messaging-resources[Authorization]
+** xref:configuring-authorization-{context}[Authorization]
+
If necessary, configure policies to control which messaging resources clients are able to access on the router network.
-** xref:routing[Routing]
+** xref:configuring-routing-{context}[Routing]
+
{RouterName} automatically routes messages without any configuration: clients can send messages to the router network, and the router automatically routes them to their destinations. However, you can configure the routing to meet your exact requirements. You can configure the routing patterns to be used for certain addresses, create waypoints and autolinks to route messages through broker queues, and create link routes to connect clients to brokers.
-** xref:logging[Logging]
+** xref:configuring-logging-{context}[Logging]
+
You can set the default logging configuration to ensure that events are logged at the correct level for your environment.
-. xref:starting-router-{context}[Start the router].
-
. Repeat this workflow for each additional router that you want to add to the router network.
diff --git a/docs/books/modules/user-guide/router-management.adoc b/docs/books/modules/user-guide/router-management.adoc
index f7901f2..dc8f177 100644
--- a/docs/books/modules/user-guide/router-management.adoc
+++ b/docs/books/modules/user-guide/router-management.adoc
@@ -44,4 +44,4 @@
.Additional resources
-* xref:monitoring-managing-router-network[]
+* xref:management[Management]
diff --git a/docs/books/modules/user-guide/router-security.adoc b/docs/books/modules/user-guide/router-security.adoc
index 257c4d8..a661da8 100644
--- a/docs/books/modules/user-guide/router-security.adoc
+++ b/docs/books/modules/user-guide/router-security.adoc
@@ -40,4 +40,4 @@
* xref:securing-network-connections-{context}[]
-* xref:authorizing-access-to-messaging-resources[]
+* xref:configuring-authorization-{context}[]
diff --git a/docs/books/modules/user-guide/routing-messages-through-broker-queues.adoc b/docs/books/modules/user-guide/routing-messages-through-broker-queues.adoc
new file mode 100644
index 0000000..21148a7
--- /dev/null
+++ b/docs/books/modules/user-guide/routing-messages-through-broker-queues.adoc
@@ -0,0 +1,116 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// configuring-brokered-messaging.adoc
+
+[id='routing-messages-through-broker-queues-{context}']
+= Routing messages through broker queues
+
+You can route messages to and from a broker queue to provide clients with access to the queue through a router. In this scenario, clients connect to a router to send and receive messages, and the router routes the messages to or from the broker queue.
+
+You can route messages to a queue hosted on a single broker, or route messages to a _sharded queue_ distributed across multiple brokers.
+
+.Procedure
+
+. In the `{RouterConfigFile}` configuration file, add a waypoint address for the broker queue.
++
+--
+A waypoint address identifies a queue on a broker to which you want to route messages. This example adds a waypoint address for the `my_queue` queue:
+
+[options="nowrap",subs="+quotes"]
+----
+address {
+ prefix: my_queue
+ waypoint: yes
+}
+----
+
+`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue to which you want to send messages. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
++
+include::{FragmentDir}/fragment-prefix-matching-definition.adoc[]
++
+include::{FragmentDir}/fragment-pattern-matching-definition.adoc[]
+
+`waypoint`:: Set this attribute to `yes` so that the router handles messages sent to this address as a waypoint.
+--
+
+. Connect the router to the broker.
+
+.. Add an outgoing connection to the broker if one does not exist.
++
+--
+If the queue is sharded across multiple brokers, you must add a connection for each broker. For more information, see xref:connecting-to-external-amqp-containers-{context}[].
+
+[NOTE]
+====
+If the connection to the broker fails, {RouterName} automatically attempts to reestablish the connection and reroute message deliveries to any available alternate destinations. However, some deliveries could be returned to the sender with a `RELEASED` or `MODIFIED` disposition. Therefore, you should ensure that your clients can handle these deliveries appropriately (generally by resending them).
+====
+--
+
+.. If you want to send messages to the broker queue, add an _outgoing_ autolink to the broker queue.
++
+--
+If the queue is sharded across multiple brokers, you must add an outgoing autolink for each broker.
+
+This example configures an outgoing auto link to send messages to a broker queue:
+
+[options="nowrap",subs="+quotes"]
+----
+autoLink {
+ address: my_queue
+ connection: my_broker
+ direction: out
+ ...
+}
+----
+
+`address`:: The address of the broker queue. When the autolink is created, it will be attached to this address.
+`externalAddress`:: An optional alternate address for the broker queue. You use an external address if the broker queue should have a different address than that which the sender uses. In this scenario, senders send messages to the `address` address, and then the router routes them to the broker queue represented by the `externalAddress` address.
+`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
+`direction`:: Set this attribute to `out` to specify that this autolink can send messages from the router to the broker.
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_autolink[autoLink] in the `qdrouterd.conf` man page.
+--
+
+. If you want to receive messages from the broker queue, add an _incoming_ autolink from the broker queue:
++
+--
+If the queue is sharded across multiple brokers, you must add an outgoing autolink for each broker.
+
+This example configures an incoming auto link to receive messages from a broker queue:
+
+[options="nowrap",subs="+quotes"]
+----
+autoLink {
+ address: my_queue
+ connection: my_broker
+ direction: in
+ ...
+}
+----
+
+`address`:: The address of the broker queue. When the autolink is created, it will be attached to this address.
+`externalAddress`:: An optional alternate address for the broker queue. You use an external address if the broker queue should have a different address than that which the receiver uses. In this scenario, receivers receive messages from the `address` address, and the router retrieves them from the broker queue represented by the `externalAddress` address.
+`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
+`direction`:: Set this attribute to `in` to specify that this autolink can receive messages from the broker to the router.
+
+For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_autolink[autoLink] in the `qdrouterd.conf` man page.
+--
diff --git a/docs/books/modules/user-guide/installing-router.adoc b/docs/books/modules/user-guide/routing-patterns-link-routing.adoc
similarity index 61%
copy from docs/books/modules/user-guide/installing-router.adoc
copy to docs/books/modules/user-guide/routing-patterns-link-routing.adoc
index f870357..0ff3983 100644
--- a/docs/books/modules/user-guide/installing-router.adoc
+++ b/docs/books/modules/user-guide/routing-patterns-link-routing.adoc
@@ -17,15 +17,11 @@
under the License
////
-// Module included in the following assemblies:
+// This module is included in the following assemblies:
//
-// getting-started.adoc
+// understanding-link-routing.adoc
-[id='installing-router-{context}']
-= Installing {RouterName}
+[id='routing-patterns-link-routing-{context}']
+= Routing patterns for link routing
-include::{FragmentDir}/fragment-router-install-intro.adoc[]
-
-.Procedure
-
-include::{FragmentDir}/fragment-router-install-steps.adoc[]
+Routing patterns are not used with link routing, because there is a direct link between the sender and receiver. The router only makes a routing decision when it receives the initial link-attach request frame. Once the link is established, the router passes the messages along the link in a balanced distribution.
diff --git a/docs/books/modules/user-guide/routing-patterns-message-routing.adoc b/docs/books/modules/user-guide/routing-patterns-message-routing.adoc
new file mode 100644
index 0000000..510afdd
--- /dev/null
+++ b/docs/books/modules/user-guide/routing-patterns-message-routing.adoc
@@ -0,0 +1,72 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This assembly is included in the following assemblies:
+//
+// understanding-message-routing.adoc
+
+[id='routing-patterns-message-routing-{context}']
+= Routing patterns
+
+Routing patterns define the paths that a message with a mobile address
+can take across a network. These routing patterns can be used for both
+direct routing, in which the router distributes messages between
+clients without a broker, and indirect routing, in which the router
+enables clients to exchange messages through a broker.
+
+Routing patterns fall into two categories: Anycast
+(Balanced and Closest) and Multicast. There is no concept of
+"unicast" in which there is only one consumer for an address.
+
+Anycast distribution delivers each message to one consumer whereas
+multicast distribution delivers each message to all consumers.
+
+Each address has one of the following routing patterns, which define the path that a message with the address can take across the messaging network:
+
+Balanced:: An anycast method that allows multiple consumers to use the same address. Each message is delivered to a single consumer only, and {RouterName} attempts to balance the traffic load across the router network.
++
+--
+If multiple consumers are attached to the same address, each router determines which outbound path should receive a message by considering each path's current number of unsettled deliveries. This means that more messages will be delivered along paths where deliveries are settled at higher rates.
+
+[NOTE]
+====
+{RouterName} neither measures nor uses message settlement time to determine which outbound path to use.
+====
+
+In this scenario, the messages are spread across both receivers regardless of path length:
+
+.Balanced Message Routing
+image::balanced-routing.png[Balanced Message Routing, align="center"]
+--
+
+Closest:: An anycast method in which every message is sent along the shortest path to reach the destination, even if there are other consumers for the same address.
++
+{RouterName} determines the shortest path based on the topology cost to reach each of the consumers. If there are multiple consumers with the same lowest cost, messages will be spread evenly among those consumers.
++
+In this scenario, all messages sent by `Sender` will be delivered to `Receiver 1`:
++
+.Closest Message Routing
+image::closest-routing.png[Closest Message Routing, align="center"]
+
+Multicast:: Messages are sent to all consumers attached to the address. Each consumer will receive one copy of the message.
++
+In this scenario, all messages are sent to all receivers:
++
+.Multicast Message Routing
+image::multicast-routing.png[Multicast Message Routing, align="center"]
diff --git a/docs/books/modules/user-guide/routing.adoc b/docs/books/modules/user-guide/routing.adoc
deleted file mode 100644
index 5a21834..0000000
--- a/docs/books/modules/user-guide/routing.adoc
+++ /dev/null
@@ -1,1058 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License
-////
-
-[id='routing']
-= Routing messages through the router network
-
-Routing is the process by which messages are delivered to their destinations. To accomplish this, {RouterName} provides two routing mechanisms: _message routing_ and _link routing_.
-
-Message routing:: Routing is performed on messages as producers send them to a router. When a message arrives on a router, the router routes the message and its _settlement_ based on the message's _address_ and _routing pattern_.
-+
---
-.Message Routing
-image::message-routing.png[Message Routing, align="center"]
-
-In this diagram, the message producer attaches a link to the router, and then sends a message over the link. When the router receives the message, it identifies the message's destination based on the message's address, and then uses its routing table to determine the best route to deliver the message either to its destination or to the next hop in the route. All dispositions (including settlement) are propagated along the same path that the original message transfer took. Flow control is handled between the sender and the router, and then between the router and the receiver.
---
-
-Link routing:: Routing is performed on link-attach frames, which are chained together to form a virtual messaging path that directly connects a sender and receiver. Once a link route is established, the transfer of message deliveries, flow frames, and dispositions is performed across the link route.
-+
---
-.Link Routing
-image::link-routing.png[Link Routing, align="center"]
-
-In this diagram, a router is connected to clients and to a broker, and it provides a link route to a queue on the broker (my_queue). The sender connects to the router, and the router propagates the link-attaches to the broker to form a direct link between the sender and the broker. The sender can begin sending messages to the queue, and the router passes the deliveries along the link route directly to the broker queue.
---
-
-== Comparison of Message Routing and Link Routing
-
-While you can use either message routing or link routing to deliver messages to a destination, they differ in several important ways. Understanding these differences will enable you to choose the proper routing approach for any particular use case.
-
-=== When to Use Message Routing
-
-Message routing is the default routing mechanism. You can use it to route messages on a per-message basis between clients directly (direct-routed messaging), or to and from broker queues (brokered messaging).
-
-Message routing is best suited to the following requirements:
-
-* Default, basic message routing.
-+
-{RouterName} automatically routes messages by default, so manual configuration is only required if you want routing behavior that is different than the default.
-
-* Message-based routing patterns.
-+
-Message routing supports both anycast and multicast routing patterns. You can load-balance individual messages across multiple consumers, and multicast (or fan-out) messages to multiple subscribers.
-
-* Sharding messages across multiple broker instances when message delivery order is not important.
-+
-Sharding messages from one producer might cause that producer's messages to be received in a different order than the order in which they were sent.
-
-Message routing is not suitable for any of the following requirements:
-
-* Dedicated path through the router network.
-+
-For inter-router transfers, all message deliveries are placed on the same inter-router link. This means that the traffic for one address might affect the delivery of the traffic for another address.
-
-* Granular, end-to-end flow control.
-+
-With message routing, end-to-end flow control is based on the settlement of deliveries and therefore might not be optimal in every case.
-
-* Transaction support.
-
-* Server-side selectors.
-
-=== When to Use Link Routing
-
-Link routing requires more detailed configuration than message routing as well as an AMQP container that can accept incoming link-attaches (typically a broker). However, link routing enables you to satisfy more advanced use cases than message routing.
-
-You can use link routing if you need to meet any of the following requirements:
-
-* Dedicated path through the router network.
-+
-With link routing, each link route has dedicated inter-router links through the network. Each link has its own dedicated message buffers, which means that the address will not have "head-of-line" blocking issues with other addresses.
-
-* Sharding messages across multiple broker instances with guaranteed delivery order.
-+
-Link routing to a sharded queue preserves the delivery order of the producer's messages by causing all messages on that link to go to the same broker instance.
-
-* End-to-end flow control.
-+
-Flow control is "real" in that credits flow across the link route from the receiver to the sender.
-
-* Transaction support.
-+
-Link routing supports local transactions to a single broker. Distributed transactions are not supported.
-
-* Server-side selectors.
-+
-With a link route, consumers can provide server-side selectors for broker subscriptions.
-
-[id='configuring-message-routing']
-== Configuring Message Routing
-
-With message routing, routing is performed on messages as producers send them to a router. When a message arrives on a router, the router routes the message and its _settlement_ based on the message's _address_ and _routing pattern_.
-
-With message routing, you can do the following:
-
-* Route messages between clients (direct-routed, or brokerless messaging)
-+
-This involves configuring an address with a routing pattern. All messages sent to the address will be routed based on the routing pattern.
-* Route messages through a broker queue (brokered messaging)
-+
-This involves configuring a waypoint address to identify the broker queue and then connecting the router to the broker. All messages sent to the waypoint address will be routed to the broker queue.
-
-=== Message Routing Flow Control
-
-{RouterName} uses a _credit-based_ flow control mechanism to ensure that producers can only send messages to a router if at least one consumer is available to receive them. Because {RouterName} does not store messages, this credit-based flow control prevents producers from sending messages when there are no consumers present.
-
-A client wishing to send a message to the router must wait until the router has provided it with credit. Attempting to publish a message without credit available will cause the client to block. Once credit is made available, the client will unblock, and the message will be sent to the router.
-
-NOTE: Most AMQP client libraries enable you to determine the amount of credit available to a producer. For more information, consult your client's documentation.
-
-=== Addresses
-
-Addresses determine how messages flow through your router network. An address designates an endpoint in your messaging network, such as:
-
-* Endpoint processes that consume data or offer a service
-* Topics that match multiple consumers to multiple producers
-* Entities within a messaging broker:
-** Queues
-** Durable Topics
-** Exchanges
-
-When a router receives a message, it uses the message's address to determine where to send the message (either its destination or one step closer to its destination).
-
-==== Mobile Addresses
-
-Routers consider addresses to be mobile such that any users of an
-address may be directly connected to any router in a network and may
-move around the topology. In cases where messages are broadcast to or
-balanced across multiple consumers, the address users may be connected
-to multiple routers in the network.
-
-Mobile addresses are rendezvous points for senders and receivers.
-Messages arrive at the mobile address and are dispatched to their
-destinations according to the routing defined for the mobile address.
-The details of these routing patterns are discussed later.
-
-Mobile addresses may be discovered during normal router operation or
-configured through management settings.
-
-===== Discovered Mobile Addresses
-
-Mobile addresses are created when a client creates a link to a source
-or destination address that is unknown to the router network.
-
-Suppose a service provider wants to offer _my-service_ that clients
-may use. The service provider must open a receiver link with source
-address _my-service_. The router creates a mobile address
-_my-service_ and propagates the address so that it is known to every
-router in the network.
-
-Later a client wants to use the service and creates a sending link
-with target address _my-service_. The router matches the service
-provider's receiver having source address _my-service_ to the client's
-sender having target address _my-service_ and routes messages between
-the two.
-
-Any number of other clients can create links to the service as
-well. The clients do not have to know where in the router network the
-service provider is physically located nor are the clients required to
-connect to a specific router to use the service. Regardless of how
-many clients are using the service the service provider needs only a
-single connection and link into the router network.
-
-Another view of this same scenario is when a client tries to use the
-service before service provider has connected to the network. In this
-case the router network creates the mobile address _my-service_ as
-before. However, since the mobile address has only client sender links
-and no receiver links the router stalls the clients and prevents them
-from sending any messages. Later, after the service provider connects
-and creates the receiver link, the router will issue credits to the
-clients and the messages will begin to flow between the clients and
-the service.
-
-The service provider can connect, disconnect, and reconnect from a
-different location without having to change any of the clients or
-their connections. Imagine having the service running on a
-laptop. One day the connection is from corporate headquarters and the
-next day the connection is from some remote location. In this case the
-service provider's computer will typically have different host IP
-addresses for each connection. Using the router network the service
-provider connects to the router network and offers the named service
-and the clients connect to the router network and consume from the
-named service. The router network routes messages between the mobile
-addresses effectively masking host IP addresses of the service
-provider and the client systems.
-
-===== Configured Mobile Addresses
-
-Mobile addresses may be configured using the router _autoLink_
-object. An address created via an _autoLink_ represents a queue,
-topic, or other service in an external broker. Logically the
-_autoLink_ addresses are treated by the router network as if the
-broker had connected to the router and offered the services itself.
-
-For each configured mobile address the router will create a single
-link to the external resource. Messages flow between sender links and
-receiver links the same regardless if the mobile address was
-discovered or configured.
-
-Multiple _autoLink_ objects may define the same address on multiple
-brokers. In this case the router network creates a sharded resource
-split between the brokers. Any client can seamlessly send and receive
-messages from either broker.
-
-Note that the brokers do not need to be clustered or federated to
-receive this treatment. The brokers may even be from different vendors
-or be different versions of the same broker yet still work together to
-provide a larger service platform.
-
-
-[id='routing-patterns-overview']
-=== Routing Patterns
-
-Routing patterns define the paths that a message with a mobile address
-can take across a network. These routing patterns can be used for both
-direct routing, in which the router distributes messages between
-clients without a broker, and indirect routing, in which the router
-enables clients to exchange messages through a broker.
-
-Routing patterns fall into two categories: Anycast
-(Balanced and Closest) and Multicast. There is no concept of
-"unicast" in which there is only one consumer for an address.
-
-Anycast distribution delivers each message to one consumer whereas
-multicast distribution delivers each message to all consumers.
-
-Each address has one of the following routing patterns, which define the path that a message with the address can take across the messaging network:
-
-Balanced:: An anycast method that allows multiple consumers to use the same address. Each message is delivered to a single consumer only, and {RouterName} attempts to balance the traffic load across the router network.
-+
---
-If multiple consumers are attached to the same address, each router determines which outbound path should receive a message by considering each path's current number of unsettled deliveries. This means that more messages will be delivered along paths where deliveries are settled at higher rates.
-
-[NOTE]
-====
-{RouterName} neither measures nor uses message settlement time to determine which outbound path to use.
-====
-
-In this scenario, the messages are spread across both receivers regardless of path length:
-
-.Balanced Message Routing
-image::balanced-routing.png[Balanced Message Routing, align="center"]
---
-
-Closest:: An anycast method in which every message is sent along the shortest path to reach the destination, even if there are other consumers for the same address.
-+
-{RouterName} determines the shortest path based on the topology cost to reach each of the consumers. If there are multiple consumers with the same lowest cost, messages will be spread evenly among those consumers.
-+
-In this scenario, all messages sent by `Sender` will be delivered to `Receiver 1`:
-+
-.Closest Message Routing
-image::closest-routing.png[Closest Message Routing, align="center"]
-
-Multicast:: Messages are sent to all consumers attached to the address. Each consumer will receive one copy of the message.
-+
-In this scenario, all messages are sent to all receivers:
-+
-.Multicast Message Routing
-image::multicast-routing.png[Multicast Message Routing, align="center"]
-
-=== Message Settlement and Reliability
-
-{RouterName} can deliver messages with the following degrees of reliability:
-
-* At most once
-* At least once
-* Exactly once
-
-The level of reliability is negotiated between the producer and the router when the producer establishes a link to the router. To achieve the negotiated level of reliability, {RouterName} treats all messages as either _pre-settled_ or _unsettled_.
-
-Pre-settled::
-Sometimes called _fire and forget_, the router settles the incoming and outgoing deliveries and propagates the settlement to the message's destination. However, it does not guarantee delivery.
-
-Unsettled::
-{RouterName} propagates the settlement between the producer and consumer. For an anycast address, the router associates the incoming delivery with the resulting outgoing delivery. Based on this association, the router propagates changes in delivery state from the consumer to the producer.
-+
-For a multicast address, the router associates the incoming delivery with all outbound deliveries. The router waits for each consumer to set their delivery's final state. After all outgoing deliveries have reached their final state, the router sets a final delivery state for the original inbound delivery and passes it to the producer.
-+
-The following table describes the reliability guarantees for unsettled messages sent to an anycast or multicast address:
-+
-[cols="20,40,40"]
-|===
-| Final disposition | Anycast | Multicast
-
-| `accepted`
-| The consumer received the message.
-a|
-Either:
-
-* All consumers received the message,
-
-* Or, at least one consumer received the message, but no consumers rejected it.
-
-| `released`
-| The message did not reach its destination.
-| The message did not reach any of the consumers.
-
-| `modified`
-| The message may or may not have reached its destination. The delivery is considered to be "in-doubt" and should be re-sent if "at least once" delivery is required.
-| The message may or may not have reached any of the consumers. However, no consumers rejected or accepted it.
-
-| `rejected`
-| The consumer rejected the message.
-| At least one consumer rejected the message.
-|===
-
-[id='prioritized-message-delivery']
-=== Configuring Addresses for Prioritized Message Delivery
-
-You can set the priority level of an address to control how {RouterName} processes messages sent to that address. Within the scope of a connection, {RouterName} attempts to process messages based on their priority. For a connection with a large volume of messages in flight, this lowers the latency for higher-priority messages.
-
-Assigning a high priority level to an address does not guarantee that messages sent to the address will be delivered before messages sent to lower-priority addresses. However, higher-priority messages will travel more quickly through the router network than they otherwise would.
-
-[NOTE]
-====
-You can also control the priority level of individual messages by setting the priority level in the message header. However, the address priority takes precedence: if you send a prioritized message to an address with a different priority level, the router will use the address priority level.
-====
-
-.Procedure
-
-* In the router's configuration file, add or edit an address and assign a priority level.
-+
---
-This example adds an address with the highest priority level. The router will attempt to deliver messages sent to this address before messages with lower priority levels.
-
-[options="nowrap",subs="+quotes"]
-----
-address {
- prefix: my-high-priority-address
- priority: 9
- ...
-}
-----
-`priority`:: The priority level to assign to all messages sent to this address. The range of valid priority levels is 0-9, in which the higher the number, the higher the priority. The default is 4.
---
-
-.Additional resources
-
-* For more information about setting the priority level in a message, see the {AmqpSpecLink}.
-
-[id='routing-messages-between-clients']
-=== Routing Messages Between Clients
-
-You can route messages between clients without using a broker. In a brokerless scenario (sometimes called _direct-routed messaging_), {RouterName} routes messages between clients directly.
-
-To route messages between clients, you configure an address with a routing distribution pattern. When a router receives a message with this address, the message is routed to its destination or destinations based on the address's routing distribution pattern.
-
-.Procedure
-
-. In the router's configuration file, add an `address` section:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-address {
- prefix: _ADDRESS_PREFIX_
- distribution: balanced|closest|multicast
- ...
-}
-----
-
-`prefix` | `pattern`:: The address or group of addresses to which the address settings should be applied. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
-+
-//tag::prefix-matching[]
-A _prefix_ matches either an exact address or the beginning segment within an address that is delimited by either a `.` or `/` character. For example, the prefix `my_address` would match the address `my_address` as well as `my_address.1` and `my_address/1`. However, it would not match `my_address1`.
-//end::prefix-matching[]
-+
-//tag::pattern-matching[]
-A _pattern_ matches an address that corresponds to a pattern. A pattern is a sequence of words delimited by either a `.` or `/` character. You can use wildcard characters to represent a word. The `*` character matches exactly one word, and the `#` character matches any sequence of zero or more words.
-+
-The `*` and `#` characters are reserved as wildcards. Therefore, you should not use them in the message address.
-+
-For more information about creating address patterns, see xref:router-address-pattern-matching[].
-+
-[NOTE]
-====
-You can convert a `prefix` value to a `pattern` by appending `/\#` to it. For example, the prefix `a/b/c` is equivalent to the pattern `a/b/c/#`.
-====
-//end::pattern-matching[]
-
-`distribution`:: The message distribution pattern. The default is `balanced`, but you can specify any of the following options:
-+
-* `balanced` - Messages sent to the address will be routed to one of the receivers, and the routing network will attempt to balance the traffic load based on the rate of settlement.
-* `closest` - Messages sent to the address are sent on the shortest path to reach the destination. It means that if there are multiple receivers for the same address, only the closest one will receive the message.
-* `multicast` - Messages are sent to all receivers that are attached to the address in a _publish/subscribe_ model.
-+
-For more information about message distribution patterns, see xref:routing-patterns-overview[Routing Patterns].
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_address[address] in the `qdrouterd.conf` man page.
---
-
-. Add the same `address` section to any other routers that need to use the address.
-+
-The `address` that you added to this router configuration file only controls how this router distributes messages sent to the address. If you have additional routers in your router network that should distribute messages for this address, then you must add the same `address` section to each of their configuration files.
-
-[id='routing-messages-through-broker']
-=== Routing Messages Through a Broker Queue
-
-You can route messages to and from a broker queue to provide clients with access to the queue through a router. In this scenario, clients connect to a router to send and receive messages, and the router routes the messages to or from the broker queue.
-
-You can route messages to a queue hosted on a single broker, or route messages to a _sharded queue_ distributed across multiple brokers.
-
-.Brokered Messaging
-image::brokered-messaging.png[Brokered Messaging, align="center"]
-
-In this diagram, the sender connects to the router and sends messages to my_queue. The router attaches an outgoing link to the broker, and then sends the messages to my_queue. Later, the receiver connects to the router and requests messages from my_queue. The router attaches an incoming link to the broker to receive the messages from my_queue, and then delivers them to the receiver.
-
-You can also route messages to a _sharded queue_, which is a single, logical queue comprised of multiple, underlying physical queues. Using queue sharding, it is possible to distribute a single queue over multiple brokers. Clients can connect to any of the brokers that hold a shard to send and receive messages.
-
-.Brokered Messaging with Sharded Queue
-image::sharded-queue-02.png[Brokered Messaging with Sharded Queue, align="center"]
-
-In this diagram, a sharded queue (my_queue) is distributed across two brokers. The router is connected to the clients and to both brokers. The sender connects to the router and sends messages to my_queue. The router attaches an outgoing link to each broker, and then sends messages to each shard (by default, the routing distribution is `balanced`). Later, the receiver connects to the router and requests all of the messages from my_queue. The router attaches an incoming link to one of the brokers to receive the messages from my_queue, and then delivers them to the receiver.
-
-.Procedure
-
-. xref:configure-waypoint-address[Add a waypoint address].
-+
-This address identifies the queue to which you want to route messages.
-. xref:connect-router-to-broker[Add autolinks to connect the router to the broker].
-+
-Autolinks connect the router to the broker queue identified by the waypoint address.
-
-. xref:connect-router-to-broker[If the queue is sharded, add autolinks for each additional broker that hosts a shard].
-
-[id='configure-waypoint-address']
-==== Configuring Waypoint Addresses
-
-A waypoint address identifies a queue on a broker to which you want to route messages. You need to configure the waypoint address on each router that needs to use the address. For example, if a client is connected to _Router A_ to send messages to the broker queue, and another client is connected to _Router B_ to receive those messages, then you would need to configure the waypoint address on both _Router A_ and _Router B_.
-
-.Prerequisites
-
-An incoming connection (`listener`) to which the clients can connect should be configured. This connection defines how the producers and consumers connect to the router to send and receive messages. For more information, see xref:listening-client-connections-{context}[].
-
-// Does the broker queue have to exist before you create the waypoint address? If it doesn't exist, will you get an error?
-
-.Procedure
-
-* Create waypoint addresses on each router that needs to use the address:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-address {
- prefix: _ADDRESS_PREFIX_
- waypoint: yes
-}
-----
-
-`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue to which you want to send messages. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
-+
-include::routing.adoc[tags=prefix-matching]
-+
-include::routing.adoc[tags=pattern-matching]
-
-`waypoint`:: Set this attribute to `yes` so that the router handles messages sent to this address as a waypoint.
---
-
-[id='connect-router-to-broker']
-==== Connecting a Router to the Broker
-
-After you add waypoint addresses to identify the broker queue, you must connect a router to the broker using autolinks.
-
-With autolinks, client traffic is handled on the router, not the broker. Clients attach their links to the router, and then the router uses internal autolinks to connect to the queue on the broker. Therefore, the queue will always have a single producer and a single consumer regardless of how many clients are attached to the router.
-
-[NOTE]
-====
-If the connection to the broker fails, {RouterName} automatically attempts to reestablish the connection and reroute message deliveries to any available alternate destinations. However, some deliveries could be returned to the sender with a `RELEASED` or `MODIFIED` disposition. Therefore, you should ensure that your clients can handle these deliveries appropriately (generally by resending them).
-====
-
-. If this router is different than the router that is connected to the clients, then add the waypoint address.
-
-. Add an outgoing connection to the broker:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-connector {
- name: _NAME_
- host: _HOST_NAME/ADDRESS_
- port: _PORT_NUMBER/NAME_
- role: route-container
- ...
-}
-----
-
-`name`:: The name of the `connector`. Specify a name that describes the broker.
-`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should connect to the broker.
-`port`:: The port number or symbolic service name on which the router should connect to the broker.
-`role`:: Specify `route-container` to indicate that this connection is for an external container (broker).
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page.
---
-
-. If you want to send messages to the broker queue, create an outgoing autolink to the broker queue:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-autoLink {
- address: _ADDRESS_
- connection: _CONNECTOR_NAME_
- direction: out
- ...
-}
-----
-
-`address`:: The address of the broker queue. When the autolink is created, it will be attached to this address.
-`externalAddress`:: An optional alternate address for the broker queue. You use an external address if the broker queue should have a different address than that which the sender uses. In this scenario, senders send messages to the `addr` address, and then the router routes them to the broker queue represented by the `externalAddress` address.
-`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
-`direction`:: Set this attribute to `out` to specify that this autolink can send messages from the router to the broker.
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_autolink[autoLink] in the `qdrouterd.conf` man page.
---
-
-. If you want to receive messages from the broker queue, create an incoming autolink from the broker queue:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-autoLink {
- address: _ADDRESS_
- connection: _CONNECTOR_NAME_
- direction: in
- ...
-}
-----
-
-`address`:: The address of the broker queue. When the autolink is created, it will be attached to this address.
-`externalAddress`:: An optional alternate address for the broker queue. You use an external address if the broker queue should have a different address than that which the receiver uses. In this scenario, receivers receive messages from the `addr` address, and the router retrieves them from the broker queue represented by the `externalAddress` address.
-`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
-`direction`:: Set this attribute to `in` to specify that this autolink can receive messages from the broker to the router.
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_autolink[autoLink] in the `qdrouterd.conf` man page.
---
-
-=== Handling Undeliverable Messages for an Address
-
-You handle undeliverable messages for an address by configuring autolinks that point to _fallback destinations_.
-A fallback destination (such as a queue on a broker) stores messages that are not directly routable to any consumers.
-
-During normal message delivery,
-{RouterName} delivers messages to the consumers that are attached to the router network.
-However, if no consumers are reachable,
-the messages are diverted to any fallback destinations that were configured for the address (if the autolinks that point to the fallback destinations are active).
-When a consumer reconnects and becomes reachable again,
-it receives the messages stored at the fallback destination.
-
-[NOTE]
-====
-{RouterName} preserves the original delivery order for messages stored at a fallback destination. However, when a consumer reconnects, any new messages produced while the queue is draining will be interleaved with the messages stored at the fallback destination.
-====
-
-.Prerequisites
-
-* The router is connected to a broker.
-+
-For more information, see xref:connecting-to-external-amqp-containers-{context}[].
-
-.Procedure
-
-This procedure enables fallback for an address
-and configures autolinks to connect to the broker queue
-that provides the fallback destination for the address.
-
-. Enable fallback destinations for the address.
-+
-[options="nowrap",subs="+quotes"]
-----
-address {
- prefix: my-address
- enableFallback: yes
-}
-----
-
-. Add an _outgoing_ autolink to a queue on the broker.
-+
---
-For the address for which you enabled fallback,
-if messages are not routable to any consumers,
-the router will use this autolink to send the messages to a queue on the broker.
-
-[options="nowrap",subs="+quotes"]
-----
-autoLink {
- address: my-address.2
- direction: out
- connection: my-broker
- fallback: yes
-}
-----
---
-
-. If you want the router to send queued messages to attached consumers as soon as they connect to the router network,
-add an _incoming_ autolink.
-+
---
-As soon as a consumer attaches to the router,
-it will receive the messages stored in the broker queue,
-along with any new messages sent by the producer.
-The original delivery order of the queued messages is preserved;
-however, the queued messages will be interleaved with the new messages.
-
-If you do not add the incoming autolink,
-the messages will be stored on the broker,
-but will not be sent to consumers when they attach to the router.
-
-[options="nowrap",subs="+quotes"]
-----
-autoLink {
- address: my-address.2
- direction: in
- connection: my-broker
- fallback: yes
-}
-----
---
-
-=== Example: Routing Messages Through Broker Queues
-
-This example shows how waypoints and autolinks can route messages through a pair of queues on a broker.
-
-==== Router Configuration
-
-[options="nowrap"]
-----
-connector { // <1>
- name: broker
- role: route-container
- host: 198.51.100.1
- port: 61617
- saslMechanisms: ANONYMOUS
-}
-
-address { // <2>
- prefix: queue
- waypoint: yes
-}
-
-autoLink { // <3>
- address: queue.first
- direction: in
- connection: broker
-}
-
-autoLink { // <4>
- address: queue.first
- direction: out
- connection: broker
-}
-
-autoLink { // <5>
- address: queue.second
- direction: in
- connection: broker
-}
-
-autoLink { // <6>
- address: queue.second
- direction: out
- connection: broker
-}
-----
-<1> The outgoing connection from the router to the broker. The `route-container` role enables the router to connect to an external AMQP container (in this case, a broker).
-<2> The namespace queue on the broker to which the router should route messages. All addresses that start with `queue` will be routed to a queue on the broker.
-<3> The incoming autolink from `queue.first` on the broker to the router.
-<4> The outgoing autolink from the router to `queue.first` on the broker.
-<5> The incoming autolink from `queue.second` on the broker to the router.
-<6> The outgoing autolink from the router to `queue.second` on the broker.
-
-==== How the Messages are Routed
-
-Initially, when the broker is offline, the autolinks are inactive.
-
-[options="nowrap"]
-----
-$ qdstat --autolinks
-AutoLinks
- addr dir phs extAddr link status lastErr
- ========================================================
- queue.first in 1 inactive
- queue.first out 0 inactive
- queue.second in 1 inactive
- queue.second out 0 inactive
-----
-
-Once the broker is online, the autolinks attempt to activate. In this case, the broker starts with the `queue.first` queue only, and the `queue.first` autolinks become active. The `queue.second` autolinks are in a failed state, because the `queue.second` queue does not exist on the broker.
-
-[options="nowrap"]
-----
-$ qdstat --autolinks
-AutoLinks
- addr dir phs extAddr link status lastErr
- ===========================================================================
- queue.first in 1 6 active
- queue.first out 0 7 active
- queue.second in 1 failed Node not found: queue.second
- queue.second out 0 failed Node not found: queue.second
-----
-
-The producer now connects to the router and sends three messages to `queue.first`.
-
-[options="nowrap"]
-----
-$ python simple_send.py -a 127.0.0.1/queue.first -m3
-all messages confirmed
-----
-
-The router's address statistics show that the messages were delivered to the queue.
-
-[options="nowrap"]
-----
-$ qdstat -a
-Router Addresses
- class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
- ========================================================================================================
- mobile queue.first 1 balanced 0 0 0 0 0 0 0 0 0
- mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0
-----
-
-The `queue.first` address appears twice in the output: once for each phase of the address. Phase 0 is for routing messages from producers to the outgoing autolink. Phase 1 is for routing messages from the incoming autolink to the subscribed consumers. In this case, Phase 0 of the address has counted three messages in the `in` column (the messages that arrived on the router from the producer), and three messages in the `out` column (the messages that were sent from the router to the broker queue).
-
-The consumer now connects to the router and receives the three messages from `queue.first`.
-
-[options="nowrap"]
-----
-$ python simple_recv.py -a 127.0.0.1:5672/queue.first -m3
-{u'sequence': int32(1)}
-{u'sequence': int32(2)}
-{u'sequence': int32(3)}
-----
-
-The router's address statistics now show that all three messages were received by the consumer from the broker queue.
-
-[options="nowrap"]
-----
-$ qdstat -a
-Router Addresses
- class addr phs distrib in-proc local remote cntnr in out thru to-proc from-proc
- ========================================================================================================
- mobile queue.first 1 balanced 0 0 0 0 3 3 0 0 0
- mobile queue.first 0 balanced 0 1 0 0 3 3 0 0 0
-----
-
-The command output shows that Phase 1 of the address was used to deliver all three messages from the queue to the consumer.
-
-[NOTE]
-====
-Even in a multi-router network, and with multiple producers and consumers for `queue.first`, all deliveries are routed through the queue on the connected broker.
-====
-
-[id='configuring-link-routing']
-== Configuring Link Routing
-
-Link routing provides an alternative strategy for brokered messaging. A link route represents a private messaging path between a sender and a receiver in which the router passes the messages between end points. You can think of a link route as a "virtual connection" or "tunnel" that travels from a sender, through the router network, to a receiver.
-
-With link routing, routing is performed on link-attach frames, which are chained together to form a virtual messaging path that directly connects a sender and receiver. Once a link route is established, the transfer of message deliveries, flow frames, and dispositions is performed across the link route.
-
-=== Link Route Addresses
-
-A link route address represents a broker queue, topic, or other service. When a client attaches a link route address to a router, the router propagates a link attachment to the broker resource identified by the address.
-
-Using link route addresses, the router network does not participate in
-aggregated message distribution. The router simply passes message
-delivery and settlement between the two end points.
-
-=== Link Route Routing Patterns
-
-Routing patterns are not used with link routing, because there is a direct link between the sender and receiver. The router only makes a routing decision when it receives the initial link-attach request frame. Once the link is established, the router passes the messages along the link in a balanced distribution.
-
-=== Link Route Flow Control
-
-Unlike message routing, with link routing, the sender and receiver handle flow control directly: the receiver grants link credits, which is the number of messages it is able to receive. The router sends them directly to the sender, and then the sender sends the messages based on the credits that the receiver granted.
-
-// What additional information do we need to provide about AMQP link flow control options? Since this is handled on the client side for link routing, should we provide a simple example with a client program that implements link flow control?
-
-[id='creating-link-route']
-=== Creating a Link Route
-
-Link routes establish a link between a sender and a receiver that travels through a router. You can configure inward and outward link routes to enable the router to receive link-attaches from clients and to send them to a particular destination.
-
-With link routing, client traffic is handled on the broker, not the router. Clients have a direct link through the router to a broker's queue. Therefore, each client is a separate producer or consumer.
-
-[NOTE]
-====
-If the connection to the broker fails, the routed links are detached, and the router will attempt to reconnect to the broker (or its backup). Once the connection is reestablished, the link route to the broker will become reachable again.
-
-From the client's perspective, the client will see the detached links (that is, the senders or receivers), but not the failed connection. Therefore, if you want the client to reattach dropped links in the event of a broker connection failure, you must configure this functionality on the client. Alternatively, you can use message routing with autolinks instead of link routing. For more information, see xref:routing-messages-through-broker[Routing Messages through a Broker Queue].
-====
-
-.Procedure
-
-. In the router configuration file, add an outgoing connection to the broker:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-connector {
- name: _NAME_
- host: _HOST_NAME/ADDRESS_
- port: _PORT_NUMBER/NAME_
- role: route-container
- ...
-}
-----
-
-`name`:: The name of the `connector`. You should specify a name that describes the broker.
-`host`:: Either an IP address (IPv4 or IPv6) or hostname on which the router should connect to the broker.
-`port`:: The port number or symbolic service name on which the router should connect to the broker.
-`role`:: Specify `route-container` to indicate that this connection is for an external container (broker).
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_connector[connector] in the `qdrouterd.conf` man page.
---
-
-. If you want clients to send local transactions to the broker, create a link route for the transaction coordinator:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-linkRoute {
- prefix: $coordinator <1>
- connection: __CONNECTOR_NAME__
- direction: in
-}
-----
-<1> The `$coordinator` prefix designates this link route as a transaction coordinator. When the client opens a transacted session, the requests to start and end the transaction are propagated along this link route to the broker.
-
-{RouterName} does not support routing transactions to multiple brokers. If you have multiple brokers in your environment, choose a single broker and route all transactions to it.
---
-
-. If you want clients to send messages on this link route, create an incoming link route:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-linkRoute {
- prefix: __ADDRESS_PREFIX__
- connection: __CONNECTOR_NAME__
- direction: in
- ...
-}
-----
-
-`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue that should be the destination for routed link-attaches. All messages that match this prefix or pattern will be distributed along the link route. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
-+
-include::routing.adoc[tags=prefix-matching]
-+
-include::routing.adoc[tags=pattern-matching]
-
-`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
-+
-If multiple brokers are connected to the router through this connection, requests for addresses matching the link route's prefix or pattern are balanced across the brokers. Alternatively, if you want to specify a particular broker, use `containerID` and add the broker's container ID.
-
-`direction`:: Set this attribute to `in` to specify that clients can send messages into the router network on this link route.
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_linkroute[linkRoute] in the `qdrouterd.conf` man page.
---
-
-. If you want clients to receive messages on this link route, create an outgoing link route:
-+
---
-[options="nowrap",subs="+quotes"]
-----
-linkRoute {
- prefix: __ADDRESS_PREFIX__
- connection: __CONNECTOR_NAME__
- direction: out
- ...
-}
-----
-
-`prefix` | `pattern`:: The address prefix or pattern that matches the broker queue from which you want to receive routed link-attaches. All messages that match this prefix or pattern will be distributed along the link route. You can specify a prefix to match an exact address or beginning segment of an address. Alternatively, you can specify a pattern to match an address using wildcards.
-+
-include::routing.adoc[tags=prefix-matching]
-+
-include::routing.adoc[tags=pattern-matching]
-
-`connection` | `containerID`:: How the router should connect to the broker. You can specify either an outgoing connection (`connection`) or the container ID of the broker (`containerID`).
-+
-If multiple brokers are connected to the router through this connection, requests for addresses matching the link route's prefix or pattern are balanced across the brokers. Alternatively, if you want to specify a particular broker, use `containerID` and add the broker's container ID.
-`direction`:: Set this attribute to `out` to specify that this link route is for receivers.
-
-For information about additional attributes, see link:{qdrouterdConfManPageUrl}#_linkroute[linkRoute] in the `qdrouterd.conf` man page.
---
-
-=== Example: Using a Link Route to Provide Client Isolation
-
-This example shows how a link route can connect a client to a message broker that is on a different private network.
-
-.Router Network with Isolated Clients
-----
-
- Public Network
- +-----------------+
- | +-----+ |
- | B1 | Rp | |
- | +/--\-+ |
- | / \ |
- | / \ |
- +----/--------\---+
- / \
- / \
- / \
- Private Net A / \ Private Net B
- +--------------/--+ +---\-------------+
- | +---/-+ | | +--\--+ |
- | B2 | Ra | | | | Rb | C1 |
- | +-----+ | | +-----+ |
- | | | |
- | | | |
- +-----------------+ +-----------------+
-----
-
-Client `C1` is constrained by firewall policy to connect to the router in its own network (`Rb`). However, it can use a link route to access queues, topics, and any other AMQP services that are provided on message brokers `B1` and `B2` -- even though they are on different networks.
-
-In this example, client `C1` needs to receive messages from `b2.event-queue`, which is hosted on broker `B2` in `Private Net A`. A link route connects the client and broker even though neither of them is aware that there is a router network between them.
-
-==== Router Configuration
-
-To enable client `C1` to receive messages from `b2.event-queue` on broker `B2`, router `Ra` must be able to do the following:
-
-* Connect to broker `B2`
-* Route links to and from broker `B2`
-* Advertise itself to the router network as a valid destination for links that have a `b2.event-queue` address.
-
-The relevant part of the configuration file for router `Ra` shows the following:
-
---
-[options="nowrap"]
-----
-connector { // <1>
- name: broker
- role: route-container
- host: 198.51.100.1
- port: 61617
- saslMechanisms: ANONYMOUS
-}
-
-linkRoute { // <2>
- prefix: b2
- direction: in
- connection: broker
-}
-
-linkRoute { // <3>
- prefix: b2
- direction: out
- connection: broker
-}
-----
-<1> The outgoing connection from the router to broker `B2`. The `route-container` role enables the router to connect to an external AMQP container (in this case, a broker).
-<2> The incoming link route for receiving links from client senders. Any sender with a target whose address begins with `b2` will be routed to broker `B2` using the `broker` connector.
-<3> The outgoing link route for sending links to client receivers. Any receivers whose source address begins with `b2` will be routed to broker `B2` using the `broker` connector.
---
-
-This configuration enables router `Ra` to advertise itself as a valid destination for targets and sources starting with `b2`. It also enables the router to connect to broker `B2`, and to route links to and from queues starting with the `b2` prefix.
-
-[NOTE]
-====
-While not required, routers `Rp` and `Rb` should also have the same configuration.
-====
-
-==== How the Client Receives Messages
-
-By using the configured link route, client `C1` can receive messages from broker `B2` even though they are on different networks.
-
-Router `Ra` establishes a connection to broker `B2`. Once the connection is open, `Ra` tells the other routers (`Rp` and `Rb`) that it is a valid destination for link routes to the `b2` prefix. This means that sender and receiver links attached to `Rb` or `Rp` will be routed along the shortest path to `Ra`, which then routes them to broker `B2`.
-
-To receive messages from the `b2.event-queue` on broker `B2`, client `C1` attaches a receiver link with a source address of `b2.event-queue` to its local router, `Rb`. Because the address matches the `b2` prefix, `Rb` routes the link to `Rp`, which is the next hop in the route to its destination. `Rp` routes the link to `Ra`, which routes it to broker `B2`. Client `C1` now has a receiver established, and it can begin receiving messages.
-
-[NOTE]
-====
-If broker `B2` is unavailable for any reason, router `Ra` will not advertise itself as a destination for `b2` addresses. In this case, routers `Rb` and `Rp` will reject link attaches that should be routed to broker `B2` with an error message indicating that there is no route available to the destination.
-====
-
-[id='router-address-pattern-matching']
-=== Pattern Matching for Addresses
-
-In some router configuration scenarios, you might need to use pattern matching to match a range of addresses rather than a single, literal address. Address patterns match any address that corresponds to the pattern.
-
-An address pattern is a sequence of tokens (typically words) that are delimited by either `.` or `/` characters. They also can contain special wildcard characters that represent words:
-
-* `*` represents exactly one word
-* `#` represents zero or more words
-
-.Address Pattern
-====
-This address contains two tokens, separated by the `/` delimiter:
-
-`my/address`
-====
-
-.Address Pattern with Wildcard
-====
-This address contains three tokens. The `*` is a wildcard, representing any single word that might be between `my` and `address`:
-
-`my/*/address`
-====
-
-The following table shows some address patterns and examples of the addresses that would match them:
-
-[options="header"]
-|===
-| This pattern... | Matches... | But not...
-
-a| `news/*`
-a| `news/europe`
-
-`news/usa`
-a| `news`
-
-`news/usa/sports`
-
-a| `news/#`
-a| `news`
-
-`news/europe`
-
-`news/usa/sports`
-a| `europe`
-
-`usa`
-
-a| `news/europe/#`
-a| `news/europe`
-
-`news/europe/sports`
-
-`news/europe/politics/fr`
-a| `news/usa`
-
-`europe`
-
-a| `news/*/sports`
-a| `news/europe/sports`
-
-`news/usa/sports`
-a| `news`
-
-`news/europe/fr/sports`
-
-|===
diff --git a/docs/books/modules/user-guide/setting-global-connection-limits.adoc b/docs/books/modules/user-guide/setting-global-connection-limits.adoc
new file mode 100644
index 0000000..5001431
--- /dev/null
+++ b/docs/books/modules/user-guide/setting-global-connection-limits.adoc
@@ -0,0 +1,44 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// authorizing-access-messaging-resources.adoc
+
+[id='setting-global-connection-limits-{context}']
+= Setting global connection limits
+
+You can create a global policy to set the incoming connection limit for a router. This limit defines the total number of concurrent client connections that can be open for this router.
+
+.Procedure
+
+* In the `{RouterConfigFile}` configuration file, add a `policy` section and set the `maxConnections`.
++
+--
+This example sets the incoming connection limit to 10000:
+
+[options="nowrap",subs="+quotes"]
+----
+policy {
+ maxConnections: 10000
+}
+----
+`maxConnections`::
+This limit is always enforced, even if no other policy settings have been defined. The limit is applied to all incoming connections regardless of remote host, authenticated user, or targeted vhost. The default (and the maximum) value is `65535`.
+--
diff --git a/docs/books/modules/user-guide/setting-resource-limits-outgoing-connections.adoc b/docs/books/modules/user-guide/setting-resource-limits-outgoing-connections.adoc
new file mode 100644
index 0000000..5a9d53b
--- /dev/null
+++ b/docs/books/modules/user-guide/setting-resource-limits-outgoing-connections.adoc
@@ -0,0 +1,80 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// setting-connection-resource-limits-messaging-endpoints.adoc
+
+[id='setting-resource-limits-outgoing-connections-{context}']
+= Setting resource limits for outgoing connections
+
+If a router establishes an outgoing connection to an external AMQP container (such as a client or broker), you can restrict the resources that the external container can access on the router by configuring a connector vhost policy.
+
+The resource limits that are defined in a connector vhost policy are applied to links that are initiated by the external AMQP container. The connector vhost policy does not restrict links that the router creates.
+
+A connector vhost policy can only be applied to a connector with a `normal` or `route-container` role. You cannot apply connector vhost policies to connectors that have `inter-router` or `edge` roles.
+
+.Prerequisites
+
+* Vhost policies are enabled for the router. For more information, see xref:enabling-vhost-policies-{context}[].
+
+.Procedure
+
+. In the `{RouterConfigFile}` configuration file, add a `vhost` section with a `$connector` user group.
++
+--
+[options="nowrap"]
+----
+vhost {
+ hostname: my-connector-policy
+ groups: {
+ $connector: {
+ sources: *
+ targets: *
+ maxSenders: 5
+ maxReceivers: 10
+ allowAnonymousSender: true
+ allowWaypointLinks: true
+ }
+ }
+}
+----
+
+`hostname`::
+A unique name to identify the connector vhost policy. This name does not represent an actual hostname; therefore, choose a name that will not conflict with an actual vhost hostname.
+
+`$connector`::
+Identifies this vhost policy as a connector vhost policy. For more information about the resource limits you can apply, see xref:creating-vhost-policies-{context}[].
+--
+
+. Apply the connector vhost policy to the connector that establishes the connection to the external AMQP container.
++
+--
+The following example applies the connector vhost policy that was configured in the previous step:
+
+[options="nowrap"]
+----
+connector {
+ host: 192.0.2.10
+ port: 5672
+ role: normal
+ policyVhost: my-connector-policy
+}
+----
+--
diff --git a/docs/books/modules/user-guide/setting-up-access-web-console.adoc b/docs/books/modules/user-guide/setting-up-access-web-console.adoc
new file mode 100644
index 0000000..2083cf7
--- /dev/null
+++ b/docs/books/modules/user-guide/setting-up-access-web-console.adoc
@@ -0,0 +1,78 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// monitoring-using-web-console.adoc
+
+[id='setting-up-access-web-console'-{context}']
+= Setting up access to {ConsoleName}
+
+Before you can access the web console, you must configure a `listener` to accept HTTP connections for the web console and serve the console files.
+
+.Procedure
+
+. On the router from which you want to access the web console, open the `{RouterConfigFile}` configuration file.
+
+. Add a `listener` to serve the console.
++
+--
+This example creates a `listener` that clients can use to access the web console:
+
+[options="nowrap",subs="+quotes"]
+----
+listener {
+ host: 0.0.0.0
+ port: 8672
+ role: normal
+ http: true
+ httpRootDir: /usr/share/qpid-dispatch/console
+}
+----
+`host`:: The IP address (IPv4 or IPv6) or hostname on which the router will listen.
+
+`port`:: The port number or symbolic service name on which the router will listen.
+
+`role`:: The role of the connection. Specify `normal` to indicate that this connection is used for client traffic.
+
+`http`:: Set this attribute to `true` to specify that this `listener` should accept HTTP connections instead of plain AMQP connections.
+
+`httpRootDir`:: Specify the absolute path to the directory that contains the web console HTML files. The default directory is the stand-alone console installation directory, usually `/usr/share/qpid-dispatch/console`.
+--
+
+. If you want to secure access to the console, secure the `listener`.
++
+--
+For more information, see xref:securing-incoming-client-connections-{context}[]. This example adds basic user name and password authentication using SASL PLAIN:
+
+[options="nowrap",subs="+quotes"]
+----
+listener {
+ host: 0.0.0.0
+ port: 8672
+ role: normal
+ http: true
+ httpRootDir: /usr/share/qpid-dispatch/console
+ authenticatePeer: yes
+ saslMechanisms: PLAIN
+}
+----
+--
+
+. If you want to set up access to the web console from any other router in the router network, repeat this procedure for each router.
diff --git a/docs/books/modules/user-guide/supported-standards-protocols.adoc b/docs/books/modules/user-guide/supported-standards-protocols.adoc
index 35ee3c4..65db7b5 100644
--- a/docs/books/modules/user-guide/supported-standards-protocols.adoc
+++ b/docs/books/modules/user-guide/supported-standards-protocols.adoc
@@ -26,8 +26,7 @@
{RouterName} supports the following industry-recognized standards and network protocols:
-* Version 1.0 of the Advanced Message Queueing Protocol (AMQP)
-* Modern TCP with IPv6
+include::{FragmentDir}/fragment-supported-standards-protocols-list.adoc[]
[NOTE]
====
@@ -36,4 +35,4 @@
.Additional resources
-* link:http://www.amqp.org/resources/download[OASIS AMQP 1.0 Specification]
+include::{FragmentDir}/fragment-supported-standards-additional-resources.adoc[]
diff --git a/docs/books/modules/user-guide/syntax-using-qdstat.adoc b/docs/books/modules/user-guide/syntax-using-qdstat.adoc
new file mode 100644
index 0000000..b393421
--- /dev/null
+++ b/docs/books/modules/user-guide/syntax-using-qdstat.adoc
@@ -0,0 +1,44 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// monitoring-using-qdstat.adoc
+
+[id='syntax-using-qdstat-{context}']
+= Syntax for using `qdstat`
+
+You can use `qdstat` with the following syntax:
+
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat __<option>__ [__<connection-options>__] [__<secure-connection-options>__]
+----
+
+This specifies:
+
+* An _option_ for the type of information to view.
+* One or more optional _connection options_ to specify a router for which to view the information.
++
+If you do not specify a connection option, `qdstat` connects to the router listening on localhost and the default AMQP port (5672).
+* The _secure connection options_ if the router for which you want to view information only accepts secure connections.
+
+.Additional resources
+
+* For more information about `qdstat`, see the {qdstatManPageLink}.
diff --git a/docs/books/modules/user-guide/troubleshooting-using-logs.adoc b/docs/books/modules/user-guide/troubleshooting-using-logs.adoc
new file mode 100644
index 0000000..c5fa4d3
--- /dev/null
+++ b/docs/books/modules/user-guide/troubleshooting-using-logs.adoc
@@ -0,0 +1,191 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// troubleshooting.adoc
+
+[id='troubleshooting-using-logs-{context}']
+= Troubleshooting using logs
+
+You can use {RouterName} log entries to help diagnose error and performance issues with the routers in your network.
+
+.Troubleshooting connections and links
+====
+In this example, `ROUTER` logs show the lifecycle of a connection and a link that is associated with it.
+
+[options="nowrap"]
+----
+2019-04-05 14:54:38.037248 -0400 ROUTER (info) [C1] Connection Opened: dir=in host=127.0.0.1:55440 vhost= encrypted=no auth=no user=anonymous container_id=95e55424-6c0a-4a5c-8848-65a3ea5cc25a props= // <1>
+2019-04-05 14:54:38.038137 -0400 ROUTER (info) [C1][L6] Link attached: dir=in source={<none> expire:sess} target={$management expire:sess} // <2>
+2019-04-05 14:54:38.041103 -0400 ROUTER (info) [C1][L6] Link lost: del=1 presett=0 psdrop=0 acc=1 rej=0 rel=0 mod=0 delay1=0 delay10=0 // <3>
+2019-04-05 14:54:38.041154 -0400 ROUTER (info) [C1] Connection Closed // <4>
+----
+<1> The connection is opened. Each connection has a unique ID (`C1`). The log also shows some information about the connection.
+<2> A link is attached over the connection. The link is identified with a unique ID (`L6`). The log also shows the direction of the link, and the source and target addresses.
+<3> The link is detached. The log shows the link's terminal statistics.
+<4> The connection is closed.
+====
+
+.Troubleshooting the network topology
+====
+In this example, on `Router.A`, the `ROUTER_HELLO` logs show that it is connected to `Router.B`, and that `Router.B` is connected to `Router.A` and `Router.C`:
+
+[options="nowrap"]
+----
+Tue Jun 7 13:50:21 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C']) // <1>
+Tue Jun 7 13:50:21 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B']) // <2>
+Tue Jun 7 13:50:22 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C'])
+Tue Jun 7 13:50:22 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B'])
+----
+<1> `Router.A` received a Hello message from `Router.B`, which can see `Router.A` and `Router.C`.
+<2> `Router.A` sent a Hello message to `Router.B`, which is the only router it can see.
+
+On `Router.B`, the `ROUTER_HELLO` log shows the same router topology from a different perspective:
+
+[options="nowrap"]
+----
+Tue Jun 7 13:50:18 2016 ROUTER_HELLO (trace) SENT: HELLO(id=Router.B area=0 inst=1465307413 seen=['Router.A', 'Router.C']) // <1>
+Tue Jun 7 13:50:18 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.A area=0 inst=1465307416 seen=['Router.B']) // <2>
+Tue Jun 7 13:50:19 2016 ROUTER_HELLO (trace) RCVD: HELLO(id=Router.C area=0 inst=1465307411 seen=['Router.B']) // <3>
+----
+<1> `Router.B` sent a Hello message to `Router.A` and `Router.C`.
+<2> `Router.B` received a Hello message from `Router.A`, which can only see `Router.B`.
+<3> `Router.B` received a Hello message from `Router.C`, which can only see `Router.B`.
+====
+
+.Tracing the link state between routers
+====
+Periodically, each router sends a Link State Request (LSR) to the other routers and receives a Link State Update (LSU) with the requested information. Exchanging the above information, each router can compute the next hops in the topology, and the related costs.
+
+In this example, the `ROUTER_LS` logs show the RA, LSR, and LSU messages sent between three routers:
+
+[options="nowrap"]
+----
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.C
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.B
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: RA(id=Router.A area=0 inst=1465308600 ls_seq=1 mobile_seq=1) // <1>
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSU(id=Router.B area=0 inst=1465308595 ls_seq=2 ls=LS(id=Router.B area=0 ls_seq=2 peers={'Router.A': 1L, 'Router.C': 1L})) // <2>
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSR(id=Router.B area=0)
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSU(id=Router.A area=0 inst=1465308600 ls_seq=1 ls=LS(id=Router.A area=0 ls_seq=1 peers={'Router.B': 1}))
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: RA(id=Router.C area=0 inst=1465308592 ls_seq=1 mobile_seq=0)
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSR(id=Router.A area=0) to: Router.C
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSR(id=Router.C area=0) // <3>
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) SENT: LSU(id=Router.A area=0 inst=1465308600 ls_seq=1 ls=LS(id=Router.A area=0 ls_seq=1 peers={'Router.B': 1}))
+Tue Jun 7 14:10:02 2016 ROUTER_LS (trace) RCVD: LSU(id=Router.C area=0 inst=1465308592 ls_seq=1 ls=LS(id=Router.C area=0 ls_seq=1 peers={'Router.B': 1L})) // <4>
+Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed next hops: {'Router.C': 'Router.B', 'Router.B': 'Router.B'} // <5>
+Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed costs: {'Router.C': 2L, 'Router.B': 1}
+Tue Jun 7 14:10:03 2016 ROUTER_LS (trace) Computed valid origins: {'Router.C': [], 'Router.B': []}
+----
+<1> `Router.A` sent LSR requests and an RA advertisement to the other routers on the network.
+<2> `Router.A` received an LSU from `Router.B`, which has two peers: `Router.A`, and `Router.C` (with a cost of `1`).
+<3> `Router.A` received an LSR from both `Router.B` and `Router.C`, and replied with an LSU.
+<4> `Router.A` received an LSU from `Router.C`, which only has one peer: `Router.B` (with a cost of `1`).
+<5> After the LSR and LSU messages are exchanged, `Router.A` computed the router topology with the related costs.
+====
+
+.Tracing the state of mobile addresses attached to a router
+====
+In this example, the `ROUTER_MA` logs show the Mobile Address Request (MAR) and Mobile Address Update (MAU) messages sent between three routers:
+
+[options="nowrap"]
+----
+Tue Jun 7 14:27:20 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[]) // <1>
+Tue Jun 7 14:27:21 2016 ROUTER_MA (trace) RCVD: MAR(id=Router.C area=0 have_seq=0) // <2>
+Tue Jun 7 14:27:21 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[])
+Tue Jun 7 14:27:22 2016 ROUTER_MA (trace) RCVD: MAR(id=Router.B area=0 have_seq=0) // <3>
+Tue Jun 7 14:27:22 2016 ROUTER_MA (trace) SENT: MAU(id=Router.A area=0 mobile_seq=1 add=['Cmy_queue', 'Dmy_queue', 'M0my_queue_wp'] del=[])
+Tue Jun 7 14:27:39 2016 ROUTER_MA (trace) RCVD: MAU(id=Router.C area=0 mobile_seq=1 add=['M0my_test'] del=[]) // <4>
+Tue Jun 7 14:27:51 2016 ROUTER_MA (trace) RCVD: MAU(id=Router.C area=0 mobile_seq=2 add=[] del=['M0my_test']) // <5>
+----
+<1> `Router.A` sent MAU messages to the other routers in the network to notify them about the addresses added for `my_queue` and `my_queue_wp`.
+<2> `Router.A` received a MAR message in response from `Router.C`.
+<3> `Router.A` received another MAR message in response from `Router.B`.
+<4> `Router.C` sent a MAU message to notify the other routers that it added and address for `my_test`.
+<5> `Router.C` sent another MAU message to notify the other routers that it deleted the address for `my_test` (because the receiver is detached).
+====
+
+.Finding information about messages sent and received by a router
+====
+In this example, the `MESSAGE` logs show that `Router.A` has sent and received some messages related to the Hello protocol, and sent and received some other messages on a link for a mobile address:
+
+[options="nowrap"]
+----
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_topo/0/Router.B/qdrouter' body='\d1\00\00\00\1b\00\00\00\04\a1\02id\a1\08R'} on link qdlink.p9XmBm19uDqx50R
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Received Message{to='amqp:/_topo/0/Router.A/qdrouter' body='\d1\00\00\00\8e\00\00\00
+\a1\06ls_se'} on link qdlink.phMsJOq7YaFsGAG
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Received Message{ body='\d1\00\00\00\10\00\00\00\02\a1\08seque'} on link qdlink.FYHqBX+TtwXZHfV
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{ body='\d1\00\00\00\10\00\00\00\02\a1\08seque'} on link qdlink.yU1tnPs5KbMlieM
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_local/qdhello' body='\d1\00\00\00G\00\00\00\08\a1\04seen\d0'} on link qdlink.p9XmBm19uDqx50R
+Tue Jun 7 14:36:54 2016 MESSAGE (trace) Sending Message{to='amqp:/_topo/0/Router.C/qdrouter' body='\d1\00\00\00\1b\00\00\00\04\a1\02id\a1\08R'} on link qdlink.p9XmBm19uDqx50R
+----
+====
+
+.Tracking configuration changes to a router
+====
+In this example, the `AGENT` logs show that on `Router.A`, `address`, `linkRoute`, and `autoLink` entities were added to the router's configuration file. When the router was started, the `AGENT` module applied these changes, and they are now viewable in the log:
+
+[options="nowrap"]
+----
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: ConnectorEntity(addr=127.0.0.1, allowRedirect=True, cost=1, host=127.0.0.1, identity=connector/127.0.0.1:5672:BROKER, idleTimeoutSeconds=16, maxFrameSize=65536, name=BROKER, port=5672, role=route-container, stripAnnotations=both, type=org.apache.qpid.dispatch.connector, verifyHostname=True)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAddressEntity(distribution=closest, identity=router.config.address/0, name=router.config.address/0, prefix=my_address, type=org.apache.qpid.dispatch.router.config.address, waypoint=False)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAddressEntity(distribution=balanced, identity=router.config.address/1, name=router.config.address/1, prefix=my_queue_wp, type=org.apache.qpid.dispatch.router.config.address, waypoint=True)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigLinkrouteEntity(connection=BROKER, direction=in, distribution=linkBalanced, identity=router.config.linkRoute/0, name=router.config.linkRoute/0, prefix=my_queue, type=org.apache.qpid.dispatch.router.config.linkRoute)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigLinkrouteEntity(connection=BROKER, direction=out, distribution=linkBalanced, identity=router.config.linkRoute/1, name=router.config.linkRoute/1, prefix=my_queue, type=org.apache.qpid.dispatch.router.config.linkRoute)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAutolinkEntity(address=my_queue_wp, connection=BROKER, direction=in, identity=router.config.autoLink/0, name=router.config.autoLink/0, type=org.apache.qpid.dispatch.router.config.autoLink)
+Tue Jun 7 15:07:32 2016 AGENT (debug) Add entity: RouterConfigAutolinkEntity(address=my_queue_wp, connection=BROKER, direction=out, identity=router.config.autoLink/1, name=router.config.autoLink/1, type=org.apache.qpid.dispatch.router.config.autoLink)
+----
+====
+
+.Troubleshooting policy and vhost access rules
+====
+In this example, the `POLICY` logs show that this router has no limits on maximum connections, and the default application policy is disabled:
+
+[options="nowrap"]
+----
+Tue Jun 7 15:07:32 2016 POLICY (info) Policy configured maximumConnections: 0, policyFolder: '', access rules enabled: 'false'
+Tue Jun 7 15:07:32 2016 POLICY (info) Policy fallback defaultApplication is disabled
+----
+====
+
+.Diagnosing errors
+====
+In this example, the `ERROR` logs show that the router failed to start when an incorrect path was specified for the router's configuration file:
+
+[options="nowrap"]
+----
+$ qdrouterd --conf my_config
+Wed Jun 15 09:53:28 2016 ERROR (error) Python: Exception: Cannot load configuration file my_config: [Errno 2] No such file or directory: 'my_config'
+Wed Jun 15 09:53:28 2016 ERROR (error) Traceback (most recent call last):
+ File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 155, in configure_dispatch
+ config = Config(filename)
+ File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 41, in __init__
+ self.load(filename, raw_json)
+ File "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py", line 123, in load
+ with open(source) as f:
+Exception: Cannot load configuration file my_config: [Errno 2] No such file or directory: 'my_config'
+
+Wed Jun 15 09:53:28 2016 MAIN (critical) Router start-up failed: Python: Exception: Cannot load configuration file my_config: [Errno 2] No such file or directory: 'my_config'
+qdrouterd: Python: Exception: Cannot load configuration file my_config: [Errno 2] No such file or directory: 'my_config'
+----
+====
+
+.Additional resources
+
+* For more information about logging modules, see xref:logging-modules-{context}[].
diff --git a/docs/books/modules/user-guide/types-policies.adoc b/docs/books/modules/user-guide/types-policies.adoc
new file mode 100644
index 0000000..0a27047
--- /dev/null
+++ b/docs/books/modules/user-guide/types-policies.adoc
@@ -0,0 +1,37 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// Module is included in the following assemblies:
+//
+// authorizing-access-messaging-resources.adoc
+
+[id='types-policies-{context}']
+= Types of policies
+
+{RouterName} provides the following types of policies to control connection and resource limits:
+
+Global policies::
+Settings for the router. A global policy defines the maximum number of incoming user connections for the router (across all messaging endpoints), and defines how the router should use vhost policies.
+
+Vhost policies::
+Connection and AMQP resource limits for a router ingress port (called an AMQP virtual host, or vhost). A vhost policy defines what a client using a particular connection can access on any messaging endpoint in the router network.
+
+The resource limits defined in global and vhost policies are applied to user connections only. The limits do not affect inter-router connections or router connections that are outbound to waypoints.
+
+Access to an AMQP resource allowed by policy for a given user connection to a given vhost is granted across the entire router network. Access restrictions are applied only at the router port to which a client is connected and only to resource requests originated by the client.
diff --git a/docs/books/modules/user-guide/using-console.adoc b/docs/books/modules/user-guide/using-console.adoc
deleted file mode 100644
index e7d24ea..0000000
--- a/docs/books/modules/user-guide/using-console.adoc
+++ /dev/null
@@ -1,138 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License
-////
-
-[id='using-router-console']
-= Using {ConsoleName}
-
-{ConsoleName} is a web console for monitoring the status and performance of {RouterName} router networks.
-
-include::{FragmentDir}/fragment-console-prereq.adoc[]
-
-== Setting up access to the web console
-
-Before you can access the web console, you must configure a `listener` to accept HTTP connections for the web console and serve the console files.
-
-.Procedure
-
-. On the router from which you want to access the web console, open the {RouterConfigFile} configuration file.
-
-. Add a `listener` to serve the console.
-+
---
-This example creates a `listener` that clients can use to access the web console:
-
-[options="nowrap",subs="+quotes"]
-----
-listener {
- host: 0.0.0.0
- port: 8672
- role: normal
- http: true
- httpRootDir: /usr/share/qpid-dispatch/console
-}
-----
-`host`:: The IP address (IPv4 or IPv6) or hostname on which the router will listen.
-
-`port`:: The port number or symbolic service name on which the router will listen.
-
-`role`:: The role of the connection. Specify `normal` to indicate that this connection is used for client traffic.
-
-`http`:: Set this attribute to `true` to specify that this `listener` should accept HTTP connections instead of plain AMQP connections.
-
-`httpRootDir`:: Specify the absolute path to the directory that contains the web console HTML files. The default directory is the stand-alone console installation directory, usually `/usr/share/qpid-dispatch/console`.
---
-
-. If you want to secure access to the console, secure the `listener`.
-+
---
-For more information, see xref:securing-incoming-client-connections-{context}[]. This example adds basic user name and password authentication using SASL PLAIN:
-
-[options="nowrap",subs="+quotes"]
-----
-listener {
- host: 0.0.0.0
- port: 8672
- role: normal
- http: true
- httpRootDir: /usr/share/qpid-dispatch/console
- authenticatePeer: yes
- saslMechanisms: PLAIN
-}
-----
---
-
-. If you want to set up access to the web console from any other router in the router network, repeat this procedure for each router.
-
-== Accessing the web console
-
-You can access the web console from a web browser.
-
-.Procedure
-
-. In a web browser, navigate to the web console URL.
-+
---
-The web console URL is the <host>:<port> from the `listener` that you created to serve the web console. For example: `localhost:8672`.
-
-The {ConsoleName} opens. If you set up user name and password authentication, the *Connect* tab is displayed.
---
-
-. If necessary, log in to the web console.
-+
---
-If you set up user name and password authentication, enter your user name and password to access the web console.
-
-The syntax for the user name is <__user__>@<__domain__>. For example: `admin@my-domain`.
---
-
-== Monitoring the router network using the web console
-
-In the web console, you use the tabs to monitor the router network.
-
-[cols="30,70"]
-|===
-| This tab... | Provides...
-
-| `Overview` | Aggregated information about routers, addresses, links, connections, and logs.
-
-| `Entities` | Detailed information about each AMQP management entity for each router in the router network. Some of the attributes have charts that you can add to the `Charts` tab.
-
-| `Topology` | A graphical view of the router network, including routers, clients, and brokers. The topology shows how the routers are connected, and how messages are flowing through the network.
-
-| `Charts` | Graphs of the information selected on the `Entities` tab.
-
-| `Message Flow` | A chord diagram showing the real-time message flow by address.
-
-| `Schema` | The management schema that controls each of the routers in the router network.
-
-|===
-
-== Closing a connection
-
-If a consumer is processing messages too slowly, or has stopped processing messages without settling its deliveries, you can close the connection. When you close the connection, the "stuck" deliveries are released (meaning they are not delivered to any consumers).
-
-.Procedure
-
-. Identify any connections with slow or stuck consumers.
-.. Navigate to menu:Overview[Connections].
-.. Click a connection, and then click *Links*.
-+
-The *Rate*, *Delayed 10 sec*, and *Delayed 1 sec* columns indicate if there are any slow or stuck consumers on the connection.
-
-. Click btn:[Close] to close the connection.
diff --git a/docs/books/modules/user-guide/vhost-policy-examples.adoc b/docs/books/modules/user-guide/vhost-policy-examples.adoc
new file mode 100644
index 0000000..73c89f7
--- /dev/null
+++ b/docs/books/modules/user-guide/vhost-policy-examples.adoc
@@ -0,0 +1,124 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// setting-connection-resource-limits-messaging-endpoints.adoc
+
+[id='vhost-policy-examples-{context}']
+= Vhost policy examples
+
+These examples demonstrate how to use vhost policies to authorize access to messaging resources.
+
+.Defining basic resource limits for a messaging endpoint
+====
+In this example, a vhost policy defines resource limits for clients connecting to the `example.com` host.
+
+[source,json,options="nowrap"]
+----
+[
+ ["vhost", {
+ "hostname": "example.com", // <1>
+ "maxConnectionsPerUser": 10, // <2>
+ "allowUnknownUser": true, // <3>
+ "groups": {
+ "admin": {
+ "users": ["admin1", "admin2"], // <4>
+ "remoteHosts": ["127.0.0.1", "::1"], // <5>
+ "sources": "*", // <6>
+ "targets": "*" // <7>
+ },
+ "$default": {
+ "remoteHosts": "*", // <8>
+ "sources": ["news*", "sports*" "chat*"], // <9>
+ "targets": "chat*" // <10>
+ }
+ }
+ }]
+]
+----
+
+<1> The rules defined in this vhost policy will be applied to any user connecting to `example.com`.
+
+<2> Each user can open up to 10 connections to the vhost.
+
+<3> Any user can connect to this vhost. Users that are not part of the `admin` group are assigned to the `$default` group.
+
+<4> If the `admin1` or `admin2` user connects to the vhost, they are assigned to the `admin` user group.
+
+<5> Users in the `admin` user group must connect from localhost. If the admin user attempts to connect from any other host, the connection will be denied.
+
+<6> Users in the admin user group can receive from any address.
+
+<7> Users in the admin user group can send to any address.
+
+<8> Any non-admin user is permitted to connect from any host.
+
+<9> Non-admin users are permitted to receive messages from any addresses that start with the `news`, `sports`, or `chat` prefixes.
+
+<10> Non-admin users are permitted to send messages to any addresses that start with the `chat` prefix.
+====
+
+.Limiting memory consumption
+====
+By using the advanced vhost policy attributes, you can control how much system buffer memory a user connection can potentially consume.
+
+In this example, a stock trading site provides services for stock traders. However, the site must also accept high-capacity, automated data feeds from stock exchanges. To prevent trading activity from consuming memory needed for the feeds, a larger amount of system buffer memory is allotted to the feeds than to the traders.
+
+This example uses the `maxSessions` and `maxSessionWindow` attributes to set the buffer memory consumption limits for each AMQP session. These settings are passed directly to the AMQP connection and session negotiations, and do not require any processing cycles on the router.
+
+This example does not show the vhost policy settings that are unrelated to buffer allocation.
+
+[source,json,options="nowrap"]
+----
+[
+ ["vhost", {
+ "hostname": "traders.com", // <1>
+ "groups": {
+ "traders": {
+ "users": ["trader1", "trader2"], // <2>
+ "maxFrameSize": 10000,
+ "maxSessionWindow": 5000000, // <3>
+ "maxSessions": 1 // <4>
+ },
+ "feeds": {
+ "users": ["nyse-feed", "nasdaq-feed"], // <5>
+ "maxFrameSize": 60000,
+ "maxSessionWindow": 1200000000, // <6>
+ "maxSessions": 3 // <7>
+ }
+ }
+ }]
+]
+----
+
+<1> The rules defined in this vhost policy will be applied to any user connecting to `traders.com`.
+
+<2> The `traders` group includes `trader1`, `trader2`, and any other user defined in the list.
+
+<3> At most, 5,000,000 bytes of data can be in flight on each session.
+
+<4> Only one session per connection is allowed.
+
+<5> The `feeds` group includes two users.
+
+<6> At most, 1,200,000,000 bytes of data can be in flight on each session.
+
+<7> Up to three sessions per connection are allowed.
+====
diff --git a/docs/books/modules/user-guide/vhost-policy-hostname-pattern-matching-rules.adoc b/docs/books/modules/user-guide/vhost-policy-hostname-pattern-matching-rules.adoc
new file mode 100644
index 0000000..8478e67
--- /dev/null
+++ b/docs/books/modules/user-guide/vhost-policy-hostname-pattern-matching-rules.adoc
@@ -0,0 +1,76 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// setting-connection-resource-limits-messaging-endpoints.adoc
+
+[id='vhost-policy-hostname-pattern-matching-rules-{context}']
+= Vhost policy hostname pattern matching rules
+
+In a vhost policy, vhost hostnames can be either literal hostnames or patterns that cover a range of hostnames.
+
+A hostname pattern is a sequence of words with one or more of the following wildcard characters:
+
+* `*` represents exactly one word
+* `#` represents zero or more words
+
+The following table shows some examples of hostname patterns:
+
+[options="header"]
+|===
+| This pattern... | Matches... | But not...
+
+a| `*.example.com`
+a| `www.example.com`
+a| `example.com`
+`srv2.www.example.com`
+
+a| `#.example.com`
+a| `example.com`
+`www.example.com`
+`a.b.c.d.example.com`
+a| `myhost.com`
+
+a| `www.*.test.example.com`
+a| `www.a.test.example.com`
+a| `www.test.example.com`
+`www.a.b.c.test.example.com`
+
+a| `www.#.test.example.com`
+a| `www.test.example.com`
+`www.a.test.example.com`
+`www.a.b.c.test.example.com`
+a| `test.example.com`
+|===
+
+Vhost hostname pattern matching applies the following precedence rules:
+
+[options="header"]
+|===
+| Policy pattern | Precedence
+| Exact match | High
+| * | Medium
+| # | Low
+|===
+
+[NOTE]
+====
+{RouterName} does not permit you to create vhost hostname patterns that conflict with existing patterns. This includes patterns that can be reduced to be the same as an existing pattern. For example, you would not be able to create the `\#.#.\#.#.com` pattern if `#.com` already exists.
+====
diff --git a/docs/books/modules/user-guide/viewing-log-entries.adoc b/docs/books/modules/user-guide/viewing-log-entries.adoc
new file mode 100644
index 0000000..d822453
--- /dev/null
+++ b/docs/books/modules/user-guide/viewing-log-entries.adoc
@@ -0,0 +1,55 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License
+////
+
+// This module is included in the following assemblies:
+//
+// troubleshooting.adoc
+
+[id='viewing-log-entries-{context}']
+= Viewing log entries
+
+You may need to view log entries to diagnose errors, performance problems, and other important issues. A log entry consists of an optional timestamp, the logging module, the logging level, and the log message.
+
+.Procedure
+
+* Do one of the following:
+
+** View log entries on the console.
++
+By default, events are logged to the console, and you can view them there. However, if the `output` attribute is set for a particular logging module, then you can find those log entries in the specified location (`stderr`, `syslog`, or a file).
+
+** Use the *`qdstat --log`* command to view recent log entries.
++
+--
+You can use the `--limit` parameter to limit the number of log entries that are displayed. For more information about `qdstat`, see {qdstatManPageLink}.
+
+This example displays the last three log entries for `Router.A`:
+
+[options="nowrap",subs="+quotes"]
+----
+$ qdstat --log --limit=3 -r ROUTER.A
+Wed Jun 7 17:49:32 2019 ROUTER (none) Core action 'link_deliver'
+Wed Jun 7 17:49:32 2019 ROUTER (none) Core action 'send_to'
+Wed Jun 7 17:49:32 2019 SERVER (none) [2]:0 -> @flow(19) [next-incoming-id=1, incoming-window=61, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=1, link-credit=250, drain=false]
+----
+--
+
+.Additional resources
+
+* For more information about configuring logging modules, see xref:configuring-default-logging-{context}[].
diff --git a/docs/books/user-guide/book.adoc b/docs/books/user-guide/book.adoc
index 0a4d6c2..ace89be 100644
--- a/docs/books/user-guide/book.adoc
+++ b/docs/books/user-guide/book.adoc
@@ -23,34 +23,36 @@
= {RouterBook}
-// Overview
+= Overview
include::assemblies/user-guide/overview.adoc[leveloffset=+1]
-// Installing
-include::modules/user-guide/installing-router.adoc[leveloffset=+1]
+= Learn
+include::assemblies/user-guide/important-terms-concepts.adoc[leveloffset=+1]
-// Getting started
+= Get started
include::assemblies/user-guide/getting-started.adoc[leveloffset=+1]
-// Configuring a router network topology
-include::assemblies/user-guide/creating-router-network-topology.adoc[leveloffset=+1]
+= Install
+include::assemblies/user-guide/router-deployment-guidelines.adoc[leveloffset=+1]
+include::assemblies/user-guide/installing-router.adoc[leveloffset=+1]
-// Configuring a router
-include::assemblies/user-guide/configuring-router.adoc[leveloffset=+1]
+[id='configuration']
+= Configure
+include::modules/user-guide/configuring-router-properties.adoc[leveloffset=+1]
+include::assemblies/user-guide/configuring-network-connections.adoc[leveloffset=+1]
+include::assemblies/user-guide/securing-network-connections.adoc[leveloffset=+1]
+include::assemblies/user-guide/configuring-authorization.adoc[leveloffset=+1]
+include::assemblies/user-guide/configuring-logging.adoc[leveloffset=+1]
+include::assemblies/user-guide/configuring-routing.adoc[leveloffset=+1]
-// Routing messages through the router network
-include::modules/user-guide/routing.adoc[leveloffset=+1]
+[id='management']
+= Manage
+include::assemblies/user-guide/monitoring-using-web-console.adoc[leveloffset=+1]
+include::assemblies/user-guide/monitoring-using-qdstat.adoc[leveloffset=+1]
+include::modules/user-guide/managing-using-qdmanage.adoc[leveloffset=+1]
+include::assemblies/user-guide/troubleshooting.adoc[leveloffset=+1]
-[id="monitoring-managing-router-network"]
-== Monitoring and managing the router network
-include::modules/user-guide/starting-routers.adoc[leveloffset=+2]
-include::modules/user-guide/logging.adoc[leveloffset=+2]
-include::modules/user-guide/using-console.adoc[leveloffset=+2]
-include::modules/user-guide/monitoring-using-qdstat.adoc[leveloffset=+2]
-include::modules/user-guide/managing-using-qdmanage.adoc[leveloffset=+2]
+[appendix]
+include::modules/user-guide/amqp-mapping.adoc[leveloffset=+1]
-// Technical Details and Specifications
-include::modules/user-guide/technical-details-specifications.adoc[leveloffset=+1]
-
-// Revision information
include::revision-info.adoc[]
