diff options
| author | Josh Rosen <joshrosen@databricks.com> | 2016-04-19 10:38:10 -0700 |
|---|---|---|
| committer | Reynold Xin <rxin@databricks.com> | 2016-04-19 10:38:10 -0700 |
| commit | 947b9020b0d621bc97661a0a056297e6889936d3 (patch) | |
| tree | a845b73cf950369e618cb70795c2831bd9298080 /graphx | |
| parent | d9620e769e41541347db863907bdbd057db50823 (diff) | |
| download | spark-947b9020b0d621bc97661a0a056297e6889936d3.tar.gz spark-947b9020b0d621bc97661a0a056297e6889936d3.tar.bz2 spark-947b9020b0d621bc97661a0a056297e6889936d3.zip | |
[SPARK-14676] Wrap and re-throw Await.result exceptions in order to capture full stacktrace
When `Await.result` throws an exception which originated from a different thread, the resulting stacktrace doesn't include the path leading to the `Await.result` call itself, making it difficult to identify the impact of these exceptions. For example, I've seen cases where broadcast cleaning errors propagate to the main thread and crash it but the resulting stacktrace doesn't include any of the main thread's code, making it difficult to pinpoint which exception crashed that thread.
This patch addresses this issue by explicitly catching, wrapping, and re-throwing exceptions that are thrown by `Await.result`.
I tested this manually using https://github.com/JoshRosen/spark/commit/16b31c825197ee31a50214c6ba3c1df08148f403, a patch which reproduces an issue where an RPC exception which occurs while unpersisting RDDs manages to crash the main thread without any useful stacktrace, and verified that informative, full stacktraces were generated after applying the fix in this PR.
/cc rxin nongli yhuai anabranch
Author: Josh Rosen <joshrosen@databricks.com>
Closes #12433 from JoshRosen/wrap-and-rethrow-await-exceptions.
Diffstat (limited to 'graphx')
0 files changed, 0 insertions, 0 deletions