Skip to content

Conversation

@DaveCTurner
Copy link
Contributor

  • Asserts that taskExecutionNanos is strictly positive

  • Removes impossible startTimeNanos == -1 condition

  • Implements toString()

This last point is because there have been two recent failures of PR builds of
the following form:

  2> KKN 22, 2019 11:40:12 PM com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler uncaughtException
  2> WARNING: Uncaught exception in thread: Thread[elasticsearch[mock_ node][search][T#1],5,TGRP-NodeTests]
  2> java.lang.AssertionError: expected task to always take longer than 0 nanoseconds, got: -1
  2> 	at __randomizedtesting.SeedInfo.seed([99E328AA85EDFC3A]:0)
  2> 	at org.elasticsearch.common.util.concurrent.QueueResizingEsThreadPoolExecutor.afterExecute(QueueResizingEsThreadPoolExecutor.java:154)
  2> 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1131)
  2> 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  2> 	at java.base/java.lang.Thread.run(Thread.java:834)

See for instance
https://scans.gradle.com/s/itejjhgbqu4uo/console-log?task=:server:test

I cannot immediately see how this can happen, but cannot deduce much from this
failure message, so have added more details to help a future investigation.

- Asserts that taskExecutionNanos is _strictly_ positive

- Removes impossible `startTimeNanos == -1` condition

- Implements `toString()`

This last point is because there have been two recent failures of PR builds of
the following form:

```
  2> KKN 22, 2019 11:40:12 PM com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler uncaughtException
  2> WARNING: Uncaught exception in thread: Thread[elasticsearch[mock_ node][search][T#1],5,TGRP-NodeTests]
  2> java.lang.AssertionError: expected task to always take longer than 0 nanoseconds, got: -1
  2> 	at __randomizedtesting.SeedInfo.seed([99E328AA85EDFC3A]:0)
  2> 	at org.elasticsearch.common.util.concurrent.QueueResizingEsThreadPoolExecutor.afterExecute(QueueResizingEsThreadPoolExecutor.java:154)
  2> 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1131)
  2> 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  2> 	at java.base/java.lang.Thread.run(Thread.java:834)
```

See for instance
https://scans.gradle.com/s/itejjhgbqu4uo/console-log?task=:server:test

I cannot immediately see how this can happen, but cannot deduce much from this
failure message, so have added more details to help a future investigation.
@DaveCTurner DaveCTurner added >non-issue :Core/Infra/Core Core issues without another label v8.0.0 v7.2.0 labels May 3, 2019
@DaveCTurner DaveCTurner requested review from dakrone and ywelsch May 3, 2019 09:36
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra

executionEWMA.addValue(taskExecutionNanos);
} else {
// wrapper (e.g. ContextPreservingAbstractRunnable) threw an exception before being able to run this task
assert taskExecutionNanos == -1 && timedRunnable.isStarted() == false && t != null :
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dakrone I'm not really sure about this, because the exception that ContextPreservingAbstractRunnable throws when shut down is re-thrown after we get here here, and goes uncaught, so the tests that are failing here look like they'd fail anyway. I'm also unsure whether we want to continue with the rest of the method, or bail out, or something else entirely.

Copy link
Contributor

@ywelsch ywelsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I would like for @dakrone to have a look here as well.

Copy link
Member

@dakrone dakrone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I am not sure about the exception throwing you mentioned either, regardless, I think this will provide additional feedback if it occurs again.

@DaveCTurner DaveCTurner added v7.3.0 and removed v7.2.0 labels May 24, 2019
@DaveCTurner
Copy link
Contributor Author

Superseded by #41810 it seems.

@DaveCTurner DaveCTurner deleted the 2019-05-03-timedrunnable-not-run branch May 24, 2019 07:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Core/Infra/Core Core issues without another label >non-issue

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants