-
Notifications
You must be signed in to change notification settings - Fork 25.6k
[Tests] Make testEngineGCDeletesSetting deterministic #38942
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
a1fadb1
7fed99a
2541491
9e8c531
1fe3866
1d88ff0
c414476
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -32,6 +32,7 @@ | |
| import org.elasticsearch.indices.IndicesService; | ||
| import org.elasticsearch.plugins.Plugin; | ||
| import org.elasticsearch.test.ESIntegTestCase; | ||
| import org.elasticsearch.threadpool.ThreadPool; | ||
|
|
||
| import java.util.Arrays; | ||
| import java.util.Collection; | ||
|
|
@@ -47,6 +48,7 @@ | |
| import static org.elasticsearch.test.hamcrest.ElasticsearchAssertions.assertThrows; | ||
| import static org.hamcrest.Matchers.containsString; | ||
| import static org.hamcrest.Matchers.equalTo; | ||
| import static org.hamcrest.Matchers.greaterThan; | ||
| import static org.hamcrest.Matchers.nullValue; | ||
|
|
||
| public class UpdateSettingsIT extends ESIntegTestCase { | ||
|
|
@@ -126,6 +128,16 @@ public List<Setting<?>> getSettings() { | |
| } | ||
| } | ||
|
|
||
| /** | ||
| * Needed by {@link UpdateSettingsIT#testEngineGCDeletesSetting()} | ||
| */ | ||
| @Override | ||
| protected Settings nodeSettings(int nodeOrdinal) { | ||
| return Settings.builder().put(super.nodeSettings(nodeOrdinal)) | ||
| .put("thread_pool.estimated_time_interval", 0) | ||
| .build(); | ||
| } | ||
|
|
||
| public void testUpdateDependentClusterSettings() { | ||
| IllegalArgumentException iae = expectThrows(IllegalArgumentException.class, () -> | ||
| client().admin().cluster().prepareUpdateSettings().setPersistentSettings(Settings.builder() | ||
|
|
@@ -435,23 +447,28 @@ public void testOpenCloseUpdateSettings() throws Exception { | |
| assertThat(getSettingsResponse.getSetting("test", "index.final"), nullValue()); | ||
| } | ||
|
|
||
| public void testEngineGCDeletesSetting() throws InterruptedException { | ||
| public void testEngineGCDeletesSetting() throws Exception { | ||
| createIndex("test"); | ||
| client().prepareIndex("test", "type", "1").setSource("f", 1).get(); | ||
| DeleteResponse response = client().prepareDelete("test", "type", "1").get(); | ||
| long seqNo = response.getSeqNo(); | ||
| long primaryTerm = response.getPrimaryTerm(); | ||
| // delete is still in cache this should work | ||
| client().prepareIndex("test", "type", "1").setSource("f", 2).setIfSeqNo(seqNo).setIfPrimaryTerm(primaryTerm).get(); | ||
| client().admin().indices().prepareUpdateSettings("test").setSettings(Settings.builder().put("index.gc_deletes", 0)).get(); | ||
| assertAcked(client().admin().indices().prepareUpdateSettings("test").setSettings(Settings.builder().put("index.gc_deletes", 0))); | ||
|
|
||
| response = client().prepareDelete("test", "type", "1").get(); | ||
| seqNo = response.getSeqNo(); | ||
| Thread.sleep(300); // wait for cache time to change TODO: this needs to be solved better. To be discussed. | ||
|
|
||
| // Make sure the time has advanced for InternalEngine#resolveDocVersion() | ||
| for (ThreadPool threadPool : internalCluster().getInstances(ThreadPool.class)) { | ||
| long startTime = threadPool.relativeTimeInMillis(); | ||
| assertBusy(() -> assertThat(threadPool.relativeTimeInMillis(), greaterThan(startTime))); | ||
| } | ||
|
|
||
| // delete is should not be in cache | ||
| assertThrows(client().prepareIndex("test", "type", "1").setSource("f", 3).setIfSeqNo(seqNo).setIfPrimaryTerm(primaryTerm), | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Wouldn’t it be enough to assert busy and remove the sleep?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess so, this solution just makes more visible of what's happening and less "brute force".
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The goal of the test is to make sure that once time moves the delete is forgotten. If we busy spin on the indexing request (instead of on time - which is what I think Jason refers to with sleep), we will have different semantics as some indexing ops may succeed, changing the dynamics of the test (it now will check that a CASed index operation fails if it's base is an index op, rather than a delete op).
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ah, yeah. Didn't even think that the assertBusy would potentially execute the prepareIndex request multiple times.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @bleskes Sorry to be unclear. I meant busy spin waiting for the cached time to advance. So instead of sleeping for it to happen, assert that it has happened, busily since it happens in the background.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jasontedor You mean this: 9e8c531#diff-2f68a8c77a0935a6ec75d0cc4878e86aR466 |
||
| VersionConflictEngineException.class); | ||
|
|
||
| } | ||
|
|
||
| public void testUpdateSettingsWithBlocks() { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we make
ThreadPool#ESTIMATED_TIME_INTERVAL_SETTINGa setting that has0as an inclusive lower bound? I am fine with that in a follow up.