Add thread pool tests for watcher system indices #107591
Conversation
williamrandolph
added
>test
elasticsearchmachine
added
the
Team:Data Management
|
Pinging @elastic/es-data-management (Team:Data Management) |
| public void testWatcherThreadPools() { | ||
| runWithBlockedThreadPools(() -> { | ||
| { | ||
| // write |
There was a problem hiding this comment.
Are there any Watcher actions that will trigger a bulk request? That's a case that I don't have covered.
|
Do you also want to be testing that watcher history gets written in this case? Or are you just concerned with the |
|
@masseyke |
|
I've added a test verifying that the triggered watches service can write and search data when thread pools are blocked. I couldn't make anything work with the public API, so I used an instance of the service directly. |
williamrandolph
changed the title
| protected Settings nodeSettings(int nodeOrdinal, Settings otherSettings) { | ||
| return Settings.builder() | ||
| .put(super.nodeSettings(nodeOrdinal, otherSettings)) | ||
| // if watcher is running, it may try to use blocked threads |
There was a problem hiding this comment.
todo: remove out of date comment
|
@elasticmachine update branch |
|
@elasticmachine ok to test |
|
buildkite test this |
Watcher is a system index, so gets, searches, and writes should be directed to system thread pools. This new integration test verifies that some basic Watcher operations succeed when user thread pools are completely blocked, using the test case class added in #106915.
I borrowed from
AbstractWatcherIntegrationTestCaseto get this working, so let me know if I got anything wrong in the borrowing.