Core: SerialMergeScheduler never triggers index throttling #8405
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a deprecated merge scheduler (already removed in master), but is still available in 1.3, 1.4, 1.5.
When you pick this merged scheduler, there is a bug that causes index throttling to not kick in, which means it's possible to accumulate way too many segments in the index.
Furthermore, this can then cause Elasticsearch to take a long time (> 30 seconds default timeout for e.g. a delete index request, resulting in a "Delete Index failed - not acked" from ElasticsearchIntegrationTest) to close the index, since it has a merge thread holding InternalEngine.readLock, stuck in IndexWriter.maybeMerge. I'll address this issue separately; fixing SMS (here) should fix most of the false test failures.
I also fixed IndexStatsTests.throttleTests to fail if it never saw index throttling kick in after up to 5 minutes of crazy merges.