[#2085] Added discussion to ARM per review

doc/sphinx/arm/hooks-ha.rst - added a note to passive backup
section discussing queue lengths and warning.

diff --git a/doc/sphinx/arm/hooks-ha.rst b/doc/sphinx/arm/hooks-ha.rst
index 9f3d6ed9b53a16c3bdc08083f2676f8d04f8bafa..37f7bc976813030c08cbf32adb093d28083ee65b 100644 (file)
--- a/doc/sphinx/arm/hooks-ha.rst
+++ b/doc/sphinx/arm/hooks-ha.rst
@@ -1076,6 +1076,25 @@ is more important than consistency of the lease information between the
 primary and the backups, and in all cases when the DHCP service latency should
 be minimal.
 
+.. note::
+
+   Currently, active servers place lease updates to be sent to peers onto internal
+   queues (one queue per peer/URL).  In passive-backup mode, active servers do not
+   wait for lease udpates to be acknowledged thus during times of heavy client
+   traffic it is possible for the number of lease updates queued for transimission
+   to accumulate faster than they can be delivered.  As client traffic lessens the
+   queues begin to empty.  As of Kea 2.0.0, active servers monitor the size of
+   these queues and will emit periodic warnings (see HTTP_CILENT_QUEUE_SIZE_GROWING
+   in :ref:`kea-messages`)
+   if they perceive a queue as growing too quickly.  The warnings will cease once
+   the queue size begins to shrink. These messages are intended as a bell-weather
+   and seeing them sporadically during times of heavy traffic load does not
+   necessarily indicate a problem.  If, however, they occur continually during
+   times of routine traffic load they likely indicate potential mismatches in
+   server capibilities and/or configuration and this should be investigate as the
+   size of the queues may eventually impair an active server's ability to respond
+   to clients in a timely manner.
+
 .. _ha-sharing-lease-info:
 
 Lease Information Sharing