Github user sitalkedia commented on a diff in the pull request:
https://github.com/apache/spark/pull/18150#discussion_r119927764
--- Diff: core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala
---
@@ -1383,19 +1394,43 @@ class DAGScheduler(
*/
private[scheduler] def handleExecutorLost(
execId: String,
- filesLost: Boolean,
- maybeEpoch: Option[Long] = None) {
+ workerLost: Boolean): Unit = {
+ // if the cluster manager explicitly tells us that the entire worker
was lost, then
+ // we know to unregister shuffle output. (Note that "worker"
specifically refers to the process
+ // from a Standalone cluster, where the shuffle service lives in the
Worker.)
+ val fileLost = workerLost ||
!env.blockManager.externalShuffleServiceEnabled
+ removeExecutorAndUnregisterOutputs(
+ execId = execId,
+ fileLost = fileLost,
+ hostToUnregisterOutputs = None,
+ maybeEpoch = None)
+ }
+
+ private def removeExecutorAndUnregisterOutputs(
+ execId: String,
+ fileLost: Boolean,
+ hostToUnregisterOutputs: Option[String],
+ maybeEpoch: Option[Long] = None): Unit = {
val currentEpoch = maybeEpoch.getOrElse(mapOutputTracker.getEpoch)
if (!failedEpoch.contains(execId) || failedEpoch(execId) <
currentEpoch) {
failedEpoch(execId) = currentEpoch
logInfo("Executor lost: %s (epoch %d)".format(execId, currentEpoch))
blockManagerMaster.removeExecutor(execId)
-
- if (filesLost || !env.blockManager.externalShuffleServiceEnabled) {
- logInfo("Shuffle files lost for executor: %s (epoch
%d)".format(execId, currentEpoch))
+ if (fileLost) {
+ hostToUnregisterOutputs match {
+ case Some(host) =>
+ logInfo("Shuffle files lost for host: %s (epoch
%d)".format(host, currentEpoch))
+ case None =>
+ logInfo("Shuffle files lost for executor: %s (epoch
%d)".format(execId, currentEpoch))
+ }
// TODO: This will be really slow if we keep accumulating shuffle
map stages
for ((shuffleId, stage) <- shuffleIdToMapStage) {
- stage.removeOutputsOnExecutor(execId)
+ hostToUnregisterOutputs match {
--- End diff --
I don't think that would be the ideal behavior in case of fetch failure.
Consider the case where the DAG looks like this 1 -> 2 -> 3, if we see any
fetch failure while running stage 3, the current behavior invalidates the files
in stage 2 as well as stage 1. That way we make sure we rerun the tasks in
stage 1 first then stage 2 and at last stage 3.
If we do not invalidate the files in stage 1 (as per @Josh's suggestion),
then we would unnecessarily rerun the tasks in stage 2 to encounter another
fetch failure and realize that the files for stage 1 are also missing. This
behavior would introduce significant latency overhead.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
