diff options
| author |   Saryu Shah <ss3917@att.com> | 2018-05-15 20:30:13 +0000 |
|---|---|---|
| committer | Saryu Shah <ss3917@att.com> | 2018-05-15 20:30:13 +0000 |
| commit | 7cb31ae10ead5a8e87ed90732abe43451535d49f (patch) | |
| tree | 5b11368a34c95efa26bd837d4c23394d152fb239 | |
| parent | 97ff534fdf663ba97a4ba02fec6ef4d2c9368081 (diff) | |
Documentation edits for pooling
Documentation edits for pooling and locks
-------------------------------------------------------------
Change-Id: I1b594db33437f9c9d43902ec448bcd205093beaf
Issue-ID: POLICY-536
Signed-off-by: Saryu Shah <ss3917@att.com>
| -rw-r--r-- | docs/platform/feature_pooling.rst | 8 | ||||
| -rw-r--r-- | docs/platform/swarch_pdp.rst | 4 |
2 files changed, 6 insertions, 6 deletions
diff --git a/docs/platform/feature_pooling.rst b/docs/platform/feature_pooling.rst index 5ed3de18a..f7d3579dd 100644 --- a/docs/platform/feature_pooling.rst +++ b/docs/platform/feature_pooling.rst @@ -27,11 +27,11 @@ Assumptions and Limitations Key Points ^^^^^^^^^^ * Requests are received on a common DMaaP topic - * DMaaP distributes the requests randomly to the hosts - * The request topic should have at least as many partitions as there are hosts + - DMaaP distributes the requests randomly to the hosts + - The request topic should have at least as many partitions as there are hosts * Uses a single, internal DMaaP topic for all inter-host communication * Allocates buckets to each host - * Requests are assigned to buckets based on their respective “request IDs” + - Requests are assigned to buckets based on their respective “request IDs” * No session persistence * No objects copied between hosts * Requires feature(s): distributed-locking @@ -46,7 +46,7 @@ Example Scenario 5. Publish “forward” message to internal DMaaP topic, including remote host, bucket number, DMaaP topic information, and message body 6. Remote host verifies ownership of bucket, and routes the DMaaP message to its own rule engine for processing - The figure below shows several different hosts in a pool. Each host as a copy of the bucket assignments, which specifies which buckets are assigned to which hosts. Incoming requests are mapped to a bucket, and a bucket is mapped to a host, to which the request is routed. The host table includes an entry for each active host in the pool, to which one or more buckets are mapped. + The figure below shows several different hosts in a pool. Each host has a copy of the bucket assignments, which specifies which buckets are assigned to which hosts. Incoming requests are mapped to a bucket, and a bucket is mapped to a host, to which the request is routed. The host table includes an entry for each active host in the pool, to which one or more buckets are mapped. .. image:: poolingPdps.png diff --git a/docs/platform/swarch_pdp.rst b/docs/platform/swarch_pdp.rst index 7783156ac..ca9dee29d 100644 --- a/docs/platform/swarch_pdp.rst +++ b/docs/platform/swarch_pdp.rst @@ -57,8 +57,8 @@ The current extensions supported are: - `Feature Healthcheck <feature_healthcheck.html>`_ (enabled by default) - `Feature Session Persistence <feature_sesspersist.html>`_ (disabled by default) - `Feature Active/Standby Management <feature_activestdbymgmt.html>`_ (disabled by default) -- `Feature Distributed Locking <feature_locking.html>`_ (disabled by default) -- `Feature Pooling <feature_pooling.html>`_ (disabled by default) +- `Feature Distributed Locking <feature_locking.html>`_ (enabled in OOM installation by default) +- `Feature Pooling <feature_pooling.html>`_ (enabled in OOM installation by default) .. seealso:: Click on the individual feature links for more information |