diff options
| author | Reynold Xin <rxin@apache.org> | 2014-01-15 23:47:25 -0800 |
|---|---|---|
| committer | Reynold Xin <rxin@apache.org> | 2014-01-15 23:47:25 -0800 |
| commit | c06a307ca22901839df00d25fe623f6faa6af17e (patch) | |
| tree | 3f0b9db05fc7468a8ecd196b702ec1c86483552f /examples/src | |
| parent | 84595ea3e25d2f9578b3de34704da14eb02330fa (diff) | |
| parent | 718a13c179915767107bc20cd27d9480d069231c (diff) | |
| download | spark-c06a307ca22901839df00d25fe623f6faa6af17e.tar.gz spark-c06a307ca22901839df00d25fe623f6faa6af17e.tar.bz2 spark-c06a307ca22901839df00d25fe623f6faa6af17e.zip | |
Merge pull request #445 from kayousterhout/exec_lost
Fail rather than hanging if a task crashes the JVM.
Prior to this commit, if a task crashes the JVM, the task (and
all other tasks running on that executor) is marked at KILLED rather
than FAILED. As a result, the TaskSetManager will retry the task
indefinitely rather than failing the job after maxFailures. Eventually,
this makes the job hang, because the Standalone Scheduler removes
the application after 10 works have failed, and then the app is left
in a state where it's disconnected from the master and waiting to reconnect.
This commit fixes that problem by marking tasks as FAILED rather than
killed when an executor is lost.
The downside of this commit is that if task A fails because another
task running on the same executor caused the VM to crash, the failure
will incorrectly be counted as a failure of task A. This should not
be an issue because we typically set maxFailures to 3, and it is
unlikely that a task will be co-located with a JVM-crashing task
multiple times.
Diffstat (limited to 'examples/src')
0 files changed, 0 insertions, 0 deletions