honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

feedback

This commit is contained in:
Boaz Leskes 2015-11-23 13:15:22 +01:00
parent c6f0798a20
commit 316f07743a
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
docs/resiliency/index.asciidoc
View File

@ -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)