diff options
author | Josh Rosen <joshrosen@databricks.com> | 2016-08-06 19:29:19 -0700 |
---|---|---|
committer | Josh Rosen <joshrosen@databricks.com> | 2016-08-06 19:29:19 -0700 |
commit | 4f5f9b670e1f1783f43feb22490613e72dcff852 (patch) | |
tree | 58837079c7ba57da7a48681fa6f0f26bd3bd181f /docs | |
parent | 2dd03886173f2f3b5c20fe14e9cdbd33480c1f36 (diff) | |
download | spark-4f5f9b670e1f1783f43feb22490613e72dcff852.tar.gz spark-4f5f9b670e1f1783f43feb22490613e72dcff852.tar.bz2 spark-4f5f9b670e1f1783f43feb22490613e72dcff852.zip |
[SPARK-16925] Master should call schedule() after all executor exit events, not only failures
## What changes were proposed in this pull request?
This patch fixes a bug in Spark's standalone Master which could cause applications to hang if tasks cause executors to exit with zero exit codes.
As an example of the bug, run
```
sc.parallelize(1 to 1, 1).foreachPartition { _ => System.exit(0) }
```
on a standalone cluster which has a single Spark application. This will cause all executors to die but those executors won't be replaced unless another Spark application or worker joins or leaves the cluster (or if an executor exits with a non-zero exit code). This behavior is caused by a bug in how the Master handles the `ExecutorStateChanged` event: the current implementation calls `schedule()` only if the executor exited with a non-zero exit code, so a task which causes a JVM to unexpectedly exit "cleanly" will skip the `schedule()` call.
This patch addresses this by modifying the `ExecutorStateChanged` to always unconditionally call `schedule()`. This should be safe because it should always be safe to call `schedule()`; adding extra `schedule()` calls can only affect performance and should not introduce correctness bugs.
## How was this patch tested?
I added a regression test in `DistributedSuite`.
Author: Josh Rosen <joshrosen@databricks.com>
Closes #14510 from JoshRosen/SPARK-16925.
Diffstat (limited to 'docs')
0 files changed, 0 insertions, 0 deletions