RUMM-2684: Observe uncaught exception in executors #1125
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Turns out we were swallowing uncaught exceptions raised during the execution of the tasks submitted via
Executor#execute
,ExecutorService#submit
orScheduledExecutorService#schedule
calls, because the behavior is like the following:Executor#execute
, then worker thread is killed and exception is printed to the console.ExecutorService#submit
orScheduledExecutorService#schedule
, then worker thread is kept running and exception is thrown on the thread is which doingFuture#get
call (normally the thread getting the result). We were always ignoring theFuture
returned after the task is submitted, so we were swallowing such exceptions.This change closes this gap by adding the hook to the
ThreadPoolExecutor#afterExecute
method, which allows to observe such uncaught exceptions.ThreadPoolExecutor#afterExecute
is called on the thread which did the actual task execution.The logic of this hook is taken from the afterExecute documentation.
Exceptions will be sent to the
devLogger
and to the internal telemetry as well.Review checklist (to be filled by reviewers)