Fix merge scheduler config settings #23391
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change fixes the retrieval of the merge scheduler config that previously used IndexSettings#getValue and failed to retrieve the current value of the max_thread_count when max_merge_count was set. Instead we now use Setting#get(Settings) which correctly retrieves the value (and default value) for all settings. This fixes a bug that appears when only max_thread_count was updated. Any value for the setting was accepted leading to a state where the merge scheduler throws exceptions (and fails any merge) and the index cannot be opened anymore (if it was closed before).
jimczi
added
:Core/Infra/Settings
rjernst
reviewed
Feb 27, 2017
There was a problem hiding this comment.
I'm confused on what the actual issue was here. The only difference between what you have done here, and what existed with getValue() was using the raw settings in IndexSettings, vs the scopedSettings. And the latter is what is still used for updating. Is this actually a problem in AbstractScopedSettings?
| @@ -69,8 +69,9 @@ | |||
| private volatile int maxMergeCount; | |||
|
|
|||
| MergeSchedulerConfig(IndexSettings indexSettings) { | |||
There was a problem hiding this comment.
Can this class be unit tested instead of depending on integration tests?
|
@rjernst if it helps reproducing the problem, I think this PR aims at fixing a problem I reported on the forum here: https://discuss.elastic.co/t/problem-updating-settings-maxthreadcount-8-should-be-maxmergecount-6/76279 |
Change Setting#get(Settings, Settings) to fallback only if the setting is present in the secondary. Replace IT with uts.
rjernst
approved these changes
Feb 28, 2017
| @@ -378,7 +377,7 @@ public final T get(Settings primary, Settings secondary) { | |||
| return get(primary); | |||
| } | |||
| if (fallbackSetting == null) { | |||
| return get(secondary); | |||
| return exists(secondary) ? get(secondary) : get(primary); | |||
There was a problem hiding this comment.
I think this block and the following one could be reordered to get the same effect?
if (exists(secondary)) {
return get(secondary);
}
if (fallbackSetting == null) {
return get(primary);
}
jimczi
added a commit
that referenced
this pull request
Feb 28, 2017
Change Setting#get(Settings, Settings) to fallback only if the setting is present in the secondary. This is needed to fix setting that relies on other settings. Replace IT with uts.
jimczi
added a commit
that referenced
this pull request
Feb 28, 2017
Change Setting#get(Settings, Settings) to fallback only if the setting is present in the secondary. This is needed to fix setting that relies on other settings. Replace IT with uts.
jimczi
added a commit
that referenced
this pull request
Feb 28, 2017
jimczi
added a commit
that referenced
this pull request
Feb 28, 2017
jimczi
added a commit
that referenced
this pull request
Feb 28, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 change fixes the retrieval of the merge scheduler config that previously used IndexSettings#getValue and failed to
retrieve the current value of the max_thread_count when max_merge_count was set.
Instead we now use Setting#get(Settings) which correctly retrieves the value (and default value) for all settings.
This fixes a bug that appears when only max_thread_count was updated. Any value for the setting was accepted leading to a state where the
merge scheduler throws exceptions (and fails any merge) and the index cannot be opened anymore (if it was closed before).