Uh oh!
There was an error while loading. Please reload this page.
[SPARK-10796][CORE]Resubmit stage while lost task in Zombie and removed TaskSetsAttempt - #8927
[SPARK-10796][CORE]Resubmit stage while lost task in Zombie and removed TaskSetsAttempt#8927suyanNone wants to merge 2 commits into
Conversation
suyanNone
commented
Sep 28, 2015
I will run a test job on the latest code, to confirm that problem exist or not... |
suyanNone
commented
Sep 28, 2015
Reproduce that, so re-open that |
SparkQA
commented
Sep 28, 2015
Test build #43057 has finished for PR 8927 at commit
|
suyanNone
commented
Sep 28, 2015
jenkins retest this please |
SparkQA
commented
Sep 28, 2015
Test build #43059 has finished for PR 8927 at commit
|
SparkQA
commented
Sep 28, 2015
Test build #43060 has finished for PR 8927 at commit
|
suyanNone
commented
Apr 20, 2016
jenkins retest this please |
SparkQA
commented
Apr 20, 2016
Test build #56344 has finished for PR 8927 at commit
|
SparkQA
commented
Apr 20, 2016
Test build #56345 has finished for PR 8927 at commit
|
| outputCommitCoordinator.stageEnd(stage.id) | ||
| listenerBus.post(SparkListenerStageCompleted(stage.latestInfo)) | ||
| taskScheduler.zombieTasks(stage.id) |
There was a problem hiding this comment.
Once stage was finished, it should make previous taskset Zombie
SparkQA
commented
Apr 22, 2016
Test build #56691 has finished for PR 8927 at commit
|
| Success, | ||
| makeMapStatus("hostA", reduceRdd.partitions.size))) | ||
| assert(shuffleStage.numAvailableOutputs === 2) | ||
| assert(mapOutputTracker.getMapSizesByExecutorId(shuffleId, 0).map(_._1).toSet === |
There was a problem hiding this comment.
For running stage , executor lost will not register outputlocs in this PR
suyanNone
commented
Apr 22, 2016
SparkQA
commented
Apr 22, 2016
Test build #56692 has finished for PR 8927 at commit
|
SparkQA
commented
May 10, 2016
Test build #58235 has finished for PR 8927 at commit
|
SparkQA
commented
May 10, 2016
Test build #58236 has finished for PR 8927 at commit
|
HyukjinKwon
commented
Jun 19, 2017
@suyanNone, I think the conflicts should be resolved at the last once (as a mergeable state). Would you be able to resolve them? |
gatorsmile
commented
Jun 27, 2017
We are closing it due to inactivity. please do reopen if you want to push it forward. Thanks! |
## What changes were proposed in this pull request? This PR proposes to close stale PRs, mostly the same instances with apache#18017 I believe the author in apache#14807 removed his account. Closesapache#7075Closesapache#8927Closesapache#9202Closesapache#9366Closesapache#10861Closesapache#11420Closesapache#12356Closesapache#13028Closesapache#13506Closesapache#14191Closesapache#14198Closesapache#14330Closesapache#14807Closesapache#15839Closesapache#16225Closesapache#16685Closesapache#16692Closesapache#16995Closesapache#17181Closesapache#17211Closesapache#17235Closesapache#17237Closesapache#17248Closesapache#17341Closesapache#17708Closesapache#17716Closesapache#17721Closesapache#17937 Added: Closesapache#14739Closesapache#17139Closesapache#17445Closesapache#18042Closesapache#18359 Added: Closesapache#16450Closesapache#16525Closesapache#17738 Added: Closesapache#16458Closesapache#16508Closesapache#17714 Added: Closesapache#17830Closesapache#14742 ## How was this patch tested? N/A Author: hyukjinkwon <gurwls223@gmail.com> Closesapache#18417 from HyukjinKwon/close-stale-pr.
We meet that problem in Spark 1.3.0, and I also reproduce on the latest version.
desc:
We know a running
ShuffleMapStagewill have multipleTaskSet: one Active TaskSet, multiple Zombie TaskSet, and mutiple removedTaskSetWe think a running
ShuffleMapStageis success only if its partition are all process success, namely each task‘s MapStatus are all add intooutputLocsMapStatus of running
ShuffleMapStagemay succeed by RemovedTaskSet1../Zombie TaskSet1 / Zombie TaskSet2 /..../ Active TaskSetN. So it had a chance that some output only hold by some RemovedTaskset or ZombieTaskSet.If lost a executor, it chanced that some lost-executor related MapStatus are succeed by some Zombie TaskSet.
In current logical, The solution to resolved that lost MapStatus problem is,
each TaskSet re-running that those tasks which succeed in lost-executor: re-add into
TaskSet's pendingTasks,and re-add it paritions into
Stage‘s pendingPartitions.but it is useless if that lost MapStatus only belong to Zombie/Removed TaskSet, it is Zombie, so will never be scheduled his
pendingTasksThe condition for resubmit stage is only if some task throws
FetchFailedException, but may the lost-executor just not empty any MapStatus of parent Stage for one of running Stages,and it‘s happen to that running
Stagewas lost a MapStatus only belong to a ZombieTask or removedTaskset.So if all Zombie TaskSets are all processed his runningTasks and Active TaskSet are all processed his pendingTask, then will removed by
TaskSchedulerImp, then that running Stage's pending partitions is still nonEmpty. it will hangs......TestCase to show problem:
main changes:
DAGScheuleronly receive Task Resubmit events from ActiveTaskSets, so it can comparependingPartitionswithShuffleMapStagemissing outputs to know whether there have some partition cannot compute according current Tasksets, and make a decision if there is a need to resubmitShuffleMapStageother changes: