-
Notifications
You must be signed in to change notification settings - Fork 25.2k
CI: EvilThreadPoolTests.testExecutionExceptionOnSinglePrioritizingThreadPoolExecutor fails #37708
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
Comments
Pinging @elastic/es-core-infra |
Seems to be a genuine problem with the PrioritizedEsThreadPoolExecutor, given this is the one failing in both builds. This code (test and thread poll) seems to have been touched 17th Jan 2019. As far as I can see, slowness in build system etc. should not be able to cause this, since the timeout is many minutes. Both: testExecutionErrorOnSinglePrioritizingThreadPoolExecutor have been failing recently. I did not manage to reproduce this locally yet. |
855801a might be the cause though I have not spotted the error. |
This is caused by Scheduler not yet logging warnings on exceptions. There is an associated todo in EvilThreadPoolTests. Working on a solution to both parts, which should stabilize this test. |
Scheduler.schedule(...) would previously assume that caller handles exception by calling get() on the returned ScheduledFuture. schedule() now returns a ScheduledCancellable that no longer gives access to the exception. Instead, any exception thrown out of a scheduled Runnable is logged as a warning. This is a continuation of elastic#28667, elastic#36317 and also fixes elastic#37708.
Opened PR: #38014 |
Fixed review comments: removed todo, use FutureUtils.cancel and removed scheduler task decoration since this adds more complexity than it benefits. This is a continuation of elastic#28667, elastic#36137 and also fixes elastic#37708.
Scheduler.schedule(...) would previously assume that caller handles exception by calling get() on the returned ScheduledFuture. schedule() now returns a ScheduledCancellable that no longer gives access to the exception. Instead, any exception thrown out of a scheduled Runnable is logged as a warning. This is a continuation of #28667, #36137 and also fixes #37708.
Scheduler.schedule(...) would previously assume that caller handles exception by calling get() on the returned ScheduledFuture. schedule() now returns a ScheduledCancellable that no longer gives access to the exception. Instead, any exception thrown out of a scheduled Runnable is logged as a warning. In this backport to 6.x, source backwards compatibility is maintained and some of the changes has therefore not been carried out (notably the signature change on Processor.Parameters.scheduler). This is a continuation of elastic#28667, elastic#36137 and also fixes elastic#37708.
Scheduler.schedule(...) would previously assume that caller handles exception by calling get() on the returned ScheduledFuture. schedule() now returns a ScheduledCancellable that no longer gives access to the exception. Instead, any exception thrown out of a scheduled Runnable is logged as a warning. In this backport to 6.x, source backwards compatibility is maintained and some of the changes has therefore not been carried out (notably the signature change on Processor.Parameters.scheduler). This is a continuation of #28667, #36137 and also fixes #37708.
Example build failure
https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+corretto-periodic/ES_BUILD_JAVA=openjdk12,label=amazon/68/
https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+6.x+intake/1095/
Reproduction line
does not reproduce locally
Example relevant log:
Frequency
10 in the last 24 hours, including PR builds
The text was updated successfully, but these errors were encountered: