-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
[CI] Test Failure in org.elasticsearch.client.BulkProcessorRetryIT#testBulkRejectionLoadWithBackoff #41324
Labels
:Distributed Coordination/Network
Http and internode communication implementations
>test-failure
Triaged test failures from CI
Comments
original-brownbear
added
:Distributed Coordination/Network
Http and internode communication implementations
>test-failure
Triaged test failures from CI
labels
Apr 18, 2019
Pinging @elastic/es-distributed |
I will mute this for now, until we're clear on how to solve this. |
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this issue
Apr 18, 2019
original-brownbear
added a commit
that referenced
this issue
Apr 18, 2019
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this issue
Apr 18, 2019
original-brownbear
added a commit
that referenced
this issue
Apr 18, 2019
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this issue
Apr 18, 2019
* The test fails for the retry backoff enabled case because the retry handler in the bulk processor hasn't been adjusted to account for elastic#40866 which now might lead to an outright rejection of the request instead of its items individually * Fixed by adding retry functionality to the top level request as well * Also fixed the duplicate test for the HLRC that wasn't handling the non-backoff case yet the same way the non-client IT did * closes elastic#41324
original-brownbear
added a commit
that referenced
this issue
Apr 18, 2019
* The test fails for the retry backoff enabled case because the retry handler in the bulk processor hasn't been adjusted to account for #40866 which now might lead to an outright rejection of the request instead of its items individually * Fixed by adding retry functionality to the top level request as well * Also fixed the duplicate test for the HLRC that wasn't handling the non-backoff case yet the same way the non-client IT did * closes #41324
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this issue
Apr 24, 2019
* The test fails for the retry backoff enabled case because the retry handler in the bulk processor hasn't been adjusted to account for elastic#40866 which now might lead to an outright rejection of the request instead of its items individually * Fixed by adding retry functionality to the top level request as well * Also fixed the duplicate test for the HLRC that wasn't handling the non-backoff case yet the same way the non-client IT did * closes elastic#41324
original-brownbear
added a commit
that referenced
this issue
Apr 24, 2019
* The test fails for the retry backoff enabled case because the retry handler in the bulk processor hasn't been adjusted to account for #40866 which now might lead to an outright rejection of the request instead of its items individually * Fixed by adding retry functionality to the top level request as well * Also fixed the duplicate test for the HLRC that wasn't handling the non-backoff case yet the same way the non-client IT did * closes #41324
This test failed again on master https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+artifactory/610/console
Does not reproduce:
|
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this issue
Apr 30, 2019
* Now that we process the bulk requests themselves on the WRITE threadpool, they can run out of retries too like the item requests even when backoff is active * Fixes elastic#41324 by using the same logic that checks failed item requests for their retry status for the top level bulk requests as well
fix incoming in #41700 (reproducible by simply lowering the queue size in this test's settings to |
original-brownbear
added a commit
that referenced
this issue
May 1, 2019
* Now that we process the bulk requests themselves on the WRITE threadpool, they can run out of retries too like the item requests even when backoff is active * Fixes #41324 by using the same logic that checks failed item requests for their retry status for the top level bulk requests as well
akhil10x5
pushed a commit
to akhil10x5/elasticsearch
that referenced
this issue
May 2, 2019
* Now that we process the bulk requests themselves on the WRITE threadpool, they can run out of retries too like the item requests even when backoff is active * Fixes elastic#41324 by using the same logic that checks failed item requests for their retry status for the top level bulk requests as well
gurkankaymak
pushed a commit
to gurkankaymak/elasticsearch
that referenced
this issue
May 27, 2019
gurkankaymak
pushed a commit
to gurkankaymak/elasticsearch
that referenced
this issue
May 27, 2019
* The test fails for the retry backoff enabled case because the retry handler in the bulk processor hasn't been adjusted to account for elastic#40866 which now might lead to an outright rejection of the request instead of its items individually * Fixed by adding retry functionality to the top level request as well * Also fixed the duplicate test for the HLRC that wasn't handling the non-backoff case yet the same way the non-client IT did * closes elastic#41324
gurkankaymak
pushed a commit
to gurkankaymak/elasticsearch
that referenced
this issue
May 27, 2019
* Now that we process the bulk requests themselves on the WRITE threadpool, they can run out of retries too like the item requests even when backoff is active * Fixes elastic#41324 by using the same logic that checks failed item requests for their retry status for the top level bulk requests as well
original-brownbear
added a commit
to original-brownbear/elasticsearch
that referenced
this issue
May 28, 2019
* Now that we process the bulk requests themselves on the WRITE threadpool, they can run out of retries too like the item requests even when backoff is active * Fixes elastic#41324 by using the same logic that checks failed item requests for their retry status for the top level bulk requests as well
original-brownbear
added a commit
that referenced
this issue
May 28, 2019
* Now that we process the bulk requests themselves on the WRITE threadpool, they can run out of retries too like the item requests even when backoff is active * Fixes #41324 by using the same logic that checks failed item requests for their retry status for the top level bulk requests as well
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
:Distributed Coordination/Network
Http and internode communication implementations
>test-failure
Triaged test failures from CI
This is a result of #40866
We're running into https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+7.x+intake/1107/console
The problem here is that by moving the bulk requests' initial handling to the WRITE pool entirely we lost the bulk processor's retry functionality for the case of the initial request getting rejected outright.
We will need to discuss whether to find a way to retry this after-all or adjust the test I think.
The text was updated successfully, but these errors were encountered: