Boaz Leskes 10 years ago
parent
commit
316f07743a
1 changed files with 5 additions and 5 deletions
  1. 5 5
      docs/resiliency/index.asciidoc

+ 5 - 5
docs/resiliency/index.asciidoc

@@ -110,7 +110,7 @@ The family of circuit breakers has greatly reduced the occurrence of OOM
 exceptions, but it is still possible to cause a node to run out of heap
 space.  The following issues have been identified:
 
-* Set a hard limit on `from`/`size` parameters {GIT}9311[#9311]. (STATUS: ONGOING)
+* Set a hard limit on `from`/`size` parameters {GIT}9311[#9311]. (STATUS: DONE, v2.1.0)
 * Prevent combinatorial explosion in aggregations from causing OOM {GIT}8081[#8081]. (STATUS: ONGOING)
 * Add the byte size of each hit to the request circuit breaker {GIT}9310[#9310]. (STATUS: ONGOING)
 
@@ -136,7 +136,7 @@ This status page is a start, but we can do a better job of explicitly documentin
 [float]
 === Do not allow stale shards to automatically be promoted to primary (STATUS: ONGOING)
 
-In some scenarios, after loss of all valid copies, a stale replica shard can be assigned as a primary. This can lead to
+In some scenarios, after the loss of all valid copies, a stale replica shard can be assigned as a primary. This can lead to
 a loss of acknowledged writes if the valid copies are not lost but are rather temporarily isolated. Work is underway
 ({GIT}14671[#14671]) to prevent the automatic promotion of a stale primary and only allow such promotion to occur when
 a system operator manually intervenes.
@@ -218,10 +218,10 @@ not a problem as the keys are dominated by the values. However, recent
 optimizations in Lucene have changed the balance causing the filter cache to
 grow beyond it's size.
 
-While we are working on a longer term solution ({GIT}9176[#9176]), we introduced
-a minimum weight of 1k for each cache entry. This puts an effective limit on the number of entries in the cache. See {GIT}8304[#8304] (STATUS: DONE, fixed in v1.4.0)
+As a temporary solution, we introduced a minimum weight of 1k for each cache entry.
+This puts an effective limit on the number of entries in the cache. See {GIT}8304[#8304] (STATUS: DONE, fixed in v1.4.0)
 
-Note: this has been solved by the move to Lucene's query cache. See {GIT}10897[#10897]
+The issue has been completely solved by the move to Lucene's query cache. See {GIT}10897[#10897]
 
 [float]
 === Ensure shard state ID is incremental (STATUS: DONE, v1.5.1)