diff --git a/topics/cache/disable.adoc b/topics/cache/disable.adoc
index 6ac53535b0..f5aa101311 100755
--- a/topics/cache/disable.adoc
+++ b/topics/cache/disable.adoc
@@ -24,3 +24,6 @@ Here's what the config looks like initially.
 
 To disable the cache set the `enabled` field to false for the cache you want to disable.  You must reboot your
 server for this change to take effect.
+
+NOTE: You must also remove the line like `"provider": "default"` from the `realmCache` configuration. Otherwise disabling cache won't work.
+
diff --git a/topics/clustering/load-balancer.adoc b/topics/clustering/load-balancer.adoc
index 9421d6547e..65a2a2e7ac 100755
--- a/topics/clustering/load-balancer.adoc
+++ b/topics/clustering/load-balancer.adoc
@@ -27,7 +27,7 @@ any black or white listing of IP addresses.
 Beyond the proxy itself, there are a few things you need to configure on the {{book.project.name}} side of things.
 If your proxy is forwarding requests via the HTTP protocol, then you need to configure {{book.project.name}} to pull the client's
 IP address from the `X-Forwarded-For` header rather than from the network packet.
-To do this, open up the profile configuration file (_standalone.xml, _standalone-ha.xml_, or _domain.xml_ depending on your
+To do this, open up the profile configuration file (_standalone.xml_, _standalone-ha.xml_, or _domain.xml_ depending on your
 <<fake/../../operating-mode.adoc#_operating-mode, operating mode>>) and look for the `"urn:jboss:domain:undertow:3.0` XML block.
 
 .`X-Forwarded-For` HTTP Config
@@ -55,7 +55,7 @@ pull this information from the AJP packets.
 .`X-Forwarded-For` AJP Config
 [source,xml]
 ----
-<<subsystem xmlns="urn:jboss:domain:undertow:3.0">
+<subsystem xmlns="urn:jboss:domain:undertow:3.0">
      <buffer-cache name="default"/>
      <server name="default-server">
          <ajp-listener name="ajp" socket-binding="ajp"/>
@@ -93,7 +93,7 @@ socket binding you also need to define.
 
 Then add a new `socket-binding` element to the `socket-binding-group` element:
 
-[source]
+[source,xml]
 ----
 
 <socket-binding-group name="standard-sockets" default-interface="public"
diff --git a/topics/clustering/serialized.adoc b/topics/clustering/serialized.adoc
index 1bd3e4aa49..30b827b046 100755
--- a/topics/clustering/serialized.adoc
+++ b/topics/clustering/serialized.adoc
@@ -4,18 +4,17 @@
 
 {{book.project.name}} cluster nodes are allowed to boot concurrenty.
 When {{book.project.name}} server instance boots up it may do some database migration, importing, or first time initializations.
-A DB lock is used to prevent start actions from conflicting ith one another when cluster nodes boot up concurrently.
+A DB lock is used to prevent start actions from conflicting with one another when cluster nodes boot up concurrently.
 
 By default, the maximum timeout for this lock is 900 seconds.  If a node is waiting on this lock for more than the timeout
-it will fail to boot.  This lock is checked every 2 seconds by default.
+it will fail to boot.
 Typically you won't need to increase/decrease the default value, but just in case it's possible to configure it in `keycloak-server.json`:
 
 [source,json]
 ----
 "dblock": {
     "jpa": {
-        "lockWaitTimeout": 900,
-        "lockRecheckTime": 2
+        "lockWaitTimeout": 900
     }
 }
 ----
diff --git a/topics/database.adoc b/topics/database.adoc
index f10fc31efb..1c3eab4ed3 100755
--- a/topics/database.adoc
+++ b/topics/database.adoc
@@ -4,7 +4,7 @@
 {{book.project.name}} comes with its own embedded Java-based relational database called H2.
 This is the default database that {{book.project.name}} will use to persist data and really only exists so that you can run the authentication
 server out of the box.  We highly recommend that you replace it with a more production ready external database.  The H2 database
-is not very viable in high concurrency situations and cannot be used in a cluster either.  The purpose of this chapter is to
+is not very viable in high concurrency situations and should not be used in a cluster either.  The purpose of this chapter is to
 show you how to connect {{book.project.name}} to a more mature database.
 
 {{book.project.name}} uses two layered technologies to persist its relational data.  The bottom layered technology is JDBC.  JDBC
diff --git a/topics/manage.adoc b/topics/manage.adoc
index aa0d2d98d4..75635e280a 100755
--- a/topics/manage.adoc
+++ b/topics/manage.adoc
@@ -4,13 +4,13 @@
 
 In the upcoming chapters, you'll often be provided two options for applying application server configuration changes to your deployment.  You'll be
 shown how to edit the _standalone.xml_ or _domain.xml_ directly.  This must be done when the server (or servers) are offline.
-Additionally, you may be shown how to apply config changes on a running server using the app server's command line interface ({{books.appserver.name}} CLI).  This chapter discusses
+Additionally, you may be shown how to apply config changes on a running server using the app server's command line interface ({{book.appserver.name}} CLI).  This chapter discusses
 how you will do this.
 
 
 === Start the {{book.appserver.name}} CLI
 
-To start the {{books.appserver.name}} CLI, you need to run the `jboss-cli` script.
+To start the {{book.appserver.name}} CLI, you need to run the `jboss-cli` script.
 
 .Linux/Unix
 [source]
diff --git a/topics/network/bind-address.adoc b/topics/network/bind-address.adoc
index 9619ed0c77..c9ed008e9f 100755
--- a/topics/network/bind-address.adoc
+++ b/topics/network/bind-address.adoc
@@ -19,7 +19,7 @@ $ standalone.sh -b 192.168.0.5
 The `-b` switch sets the IP bind address for any public interfaces.
 
 Alternatively, if you don't want to set the bind address at the command line, you can edit the profile configuration of your deployment.
-Open up the profile configuration file (_standalone.xml or _domain.xml_ depending on your
+Open up the profile configuration file (_standalone.xml_ or _domain.xml_ depending on your
 <<fake/../../operating-mode.adoc#_operating-mode, operating mode>>) and look for the `interfaces` XML block.
 
 [source,xml]