Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22771
LGTM
---
-
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/22771#discussion_r228371144
--- Diff: core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala
---
@@ -1364,6 +1385,21 @@ private[spark] class DAGScheduler
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/22771#discussion_r228354020
--- Diff: core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala
---
@@ -1364,6 +1385,21 @@ private[spark] class DAGScheduler
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22144
Thanks @tgravescs for your latest posts -- they've saved me from posting
something similar in many respects but more strongly worded.
What is bothering me (not just in the discussion
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22144
Yes, @rxin I know that I was a little unfair to you in order to make my
point sharper. Apologies. My concern is real, though
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22144
@srowen I understand and agree. What bothers me is that the block-no block
decision now often seems to be "not a regression; automatic no block" -- and
that doesn't seem r
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22144
> Itâs certainly not a blocker since itâs not a new regression
I really hate this line of argument. Somehow we seem to have slipped from
"if it is a regression, then we mu
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22771
> We can at least try to abort the tasks and still honors the interrupt on
cancel flag. It seems like best case is things actually get killed and we free
up resources, worst case se
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22771
There are long-standing questions here that I don't think have yet been
adequately answered -- cf. https://issues.apache.org/jira/browse/SPARK-17064
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22463
Where is the discussion on these utility methods no longer being
Experimental? I'm not saying that they are not stable, but the Kafka 0.10 API
in general being considered to be stable doesn't
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/22112#discussion_r213061324
--- Diff: core/src/main/scala/org/apache/spark/rdd/RDD.scala ---
@@ -1918,3 +1980,19 @@ object RDD {
new DoubleRDDFunctions(rdd.map(x
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/22112#discussion_r212395101
--- Diff: core/src/main/scala/org/apache/spark/rdd/RDD.scala ---
@@ -1876,6 +1920,22 @@ abstract class RDD[T: ClassTag](
*/
object RDD
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22176
Yes, this is better than what we had, but maybe it can be better still.
---
-
To unsubscribe, e-mail: reviews-unsubscr
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22176
@zsxwing we really should have considered whether this should be a
configuration variable instead of a fixed number of threads in any environment
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22112
I'm not a fan of the IDEMPOTENT, RANDOM_ORDER, COMPLETE_RANDOM naming.
IDEMPOTENT is fine, but I'd prefer UNORDERED and INDETERMINATE to cover the
cases of "same values in potent
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21698
> I really disagree with this.
I really agree with Tom. At this point, I think the working assumption
should be that any 2.4.0 release candidate that doesn't deliver some
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22039
> Yes, "quick hack", but, as opposed to what in these specific cases?
Yes, that is the key question. I'll admit, I haven't looked at all deeply
to try to figure out whet
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/22039
Hmmm... sorry to be late to this, but making pattern matches exhaustive by
adding a catch-all case that then throws an exception, while easy, should be
considered as a less than optimal fix
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21589
Thank you, @HyukjinKwon
There are a significant number of Spark users who use the Job Scheduler
model with a SparkContext shared across many users and many Jobs. Promoting
tools
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21589
I don't accept you assertions of what constitutes the majority and minority
of Spark users or use cases or their relative importance. As a long-time
maintainer of the Spark scheduler
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21589
It is precisely because the audience that I am concerned with is not
limited to just data scientists or notebook users and their particular needs
that I am far from convinced that exposing
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21589
@ssimeonov the purpose of a public API is not to offer hack solutions to a
subset of problems. What is needed is a high-level, declarative abstraction
that can be used to specify requested Job
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21589
No, defaultParallelism isn't more useful in that case, but that just starts
getting to my overall assessment of this JIRA and PR: It smells of defining the
problem to align with a preconception
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21589
@mridulm scheduler pools could also make the cluster-wide resource numbers
not very meaningful. I don't think the maxShare work has been merged yet (kind
of a stalled TODO on an open PR, IIRC
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/21754#discussion_r203416454
--- Diff:
sql/core/src/main/scala/org/apache/spark/sql/execution/exchange/Exchange.scala
---
@@ -85,14 +85,20 @@ case class ReusedExchangeExec
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21598
> case by case
Yes, but... this by itself makes the decision appear far too discretionary.
Instead, in any PR where you are changing the published interface or behavior
of p
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21598
@HyukjinKwon this is not new policy. It is what Apache Spark has guaranteed
in its version numbering and public API since 1.0.0. It is not a matter of
"from now on", but rather
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21598
> so we can't just change the default value in a feature release
Agreed. Once a particular interface and behavior is in our released public
API, then we effectively have a contr
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21527
Sure, as long as we are not telling users that this is something that they
can or should use, that's fine
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21527
> we can definitely update the description with more details.
Eventually, some of the motivation and advice/suggestions need to get into
the main user docs, as w
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21527
@tgravescs If there is value in making it configurable, that is all fine
and good. My argument is against making it configurable just for the sake of
making it configurable. If there is more
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21527
> We should make it configurable.
That's a debatable assertion all by itself -- and quite unfortunately,
there is no more justification for this claim in the JIRA ticket. Without pr
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/21440#discussion_r191063339
--- Diff: core/src/main/scala/org/apache/spark/storage/BlockManager.scala
---
@@ -659,6 +659,11 @@ private[spark] class BlockManager(
* Get
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/20930#discussion_r184462542
--- Diff:
core/src/test/scala/org/apache/spark/scheduler/DAGSchedulerSuite.scala ---
@@ -2399,6 +2399,84 @@ class DAGSchedulerSuite extends
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21096
As is, this PR isn't acceptable on multiple levels. Even if I were
convinced (which I am not presently) that the sequence of
`getShuffleDependencies` calls covered in this PR is the only one
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21071
@rxin +1 for each of your sentences.
---
-
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/20881#discussion_r178928945
--- Diff: docs/job-scheduling.md ---
@@ -215,6 +215,9 @@ pool), but inside each pool, jobs run in FIFO order.
For example, if you create
means
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/20881#discussion_r178886364
--- Diff: docs/job-scheduling.md ---
@@ -215,6 +215,9 @@ pool), but inside each pool, jobs run in FIFO order.
For example, if you create
means
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/20770
@squito is the master of DAGSchedulerSuite, and can provide you the best
advice on changing or adding to the existing DAGSchedulerSuite. I'll be back
from skiing next week and try to find some
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/20016#discussion_r157790330
--- Diff:
examples/src/main/scala/org/apache/spark/examples/BroadcastTest.scala ---
@@ -42,7 +42,7 @@ object BroadcastTest {
val arr1 = (0
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/19468#discussion_r151259662
--- Diff:
resource-managers/kubernetes/core/src/main/scala/org/apache/spark/scheduler/cluster/k8s/KubernetesClusterSchedulerBackend.scala
---
@@ -0,0
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/19468#discussion_r146072523
--- Diff:
resource-managers/kubernetes/core/src/main/scala/org/apache/spark/scheduler/cluster/k8s/KubernetesClusterSchedulerBackend.scala
---
@@ -0,0
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/19468
> iron out the kinks
A large chunk of the difficulty in identifying and ironing out kinks in
such a project is the difficulty of writing adequate tests of the scheduler
code.
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/19287#discussion_r140788231
--- Diff: core/src/main/scala/org/apache/spark/scheduler/TaskInfo.scala ---
@@ -93,6 +104,8 @@ class TaskInfo(
def running: Boolean
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/19194#discussion_r140340018
--- Diff:
core/src/main/scala/org/apache/spark/ExecutorAllocationManager.scala ---
@@ -619,6 +625,47 @@ private[spark] class ExecutorAllocationManager
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/19287#discussion_r140047573
--- Diff: core/src/main/scala/org/apache/spark/scheduler/TaskInfo.scala ---
@@ -66,6 +66,12 @@ class TaskInfo(
*/
var finishTime: Long
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/19115
And now I see that the title was changed to something more useful. Pardon
any offense, the end result of the title changes look good
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/19115
I realize this PR is now closed, but to follow-up on Saisai's request
concerning PR titles, I'll also note that the title of this PR isn't very
useful even after the JIRA id and component tag
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/18805
In addition to LICENSE, there is also COPYING in the v1.3.1 release:
https://github.com/facebook/zstd/blob/v1.3.1/LICENSE
https://github.com/facebook/zstd/blob/v1.3.1/COPYING
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/18950#discussion_r133344532
--- Diff:
core/src/main/scala/org/apache/spark/ExecutorAllocationManager.scala ---
@@ -602,6 +604,21 @@ private[spark] class ExecutorAllocationManager
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/18807
Yes, it doesn't really hurt anything except to be confusing cruft that has
a tendency to accumulate in POMs. If we're going to put those lines back, I
suggest that they be accompanied
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/18807
Maven is the build of reference, true; but maven itself doesn't need the
JDK version to be specified both in the scala plugin configuration and in the
compiler plugin configuration. While I
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/18807
Hmmm... that's arguably broken behavior on the part of IntelliJ or
something to be worked around in IntelliJ configuration, not by hacking our
POM. Without the POM hack, though
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/18807
These are maven-compiler-plugin configurations. We don't use
maven-compiler-plugin to compile Java code:
https://github.com/apache/spark/commit/74cda94c5e496e29f42f1044aab90cab7dbe9d38
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/18093#discussion_r129382985
--- Diff:
sql/core/src/main/scala/org/apache/spark/sql/execution/QueryExecution.scala ---
@@ -89,8 +91,22 @@ class QueryExecution(val sparkSession
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17955
@JoshRosen Yes, I agree that it is orthogonal -- at least for now. I'm
mostly just offering a heads up that if we get around to addressing
`interruptThread`, then there may also need to be some
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17955
I've looked at only the DAGScheduler changes so far. They LGTM.
---
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
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17955
@JoshRosen The hard coding of interruptThread = true within
TaskSetManager's handleSuccessfulTask to effect the killing of duplicate,
speculative attempts of a task is potentially an issue
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16165
@merlintang Marcelo's point remains the same for 2.1.1. We don't typically
backport changes to maintenance branches unless they are fixes for regression
errors or severe bugs.
---
If your
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17522#discussion_r109523328
--- Diff: docs/cluster-overview.md ---
@@ -52,7 +52,11 @@ The system currently supports three cluster managers:
* [Apache Mesos](running
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17485#discussion_r109174578
--- Diff:
core/src/main/scala/org/apache/spark/scheduler/TaskSetManager.scala ---
@@ -768,6 +767,19 @@ private[spark] class TaskSetManager
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17485#discussion_r109038854
--- Diff:
core/src/main/scala/org/apache/spark/scheduler/TaskSetManager.scala ---
@@ -768,6 +767,19 @@ private[spark] class TaskSetManager
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17297
Agreed. Let's establish what we want to do before trying to discuss the
details of how we are going to do it.
On Tue, Mar 28, 2017 at 8:17 AM, Imran Rashid <notificati...@github.
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17447
I wouldn't bother with the string interpolation change (there is a good
argument to be made that string interpolation doesn't gain you anything in
patterns like those in this PR where a single
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17088#discussion_r107286200
--- Diff: core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala
---
@@ -1365,19 +1375,43 @@ class DAGScheduler(
*/
private
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17088#discussion_r107284202
--- Diff: core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala
---
@@ -1683,11 +1716,12 @@ private[scheduler] class
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17088#discussion_r107284085
--- Diff: core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala
---
@@ -1389,8 +1423,7 @@ class DAGScheduler(
clearCacheLocs
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17088#discussion_r107283229
--- Diff: core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala
---
@@ -1331,7 +1328,20 @@ class DAGScheduler(
// TODO
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17357
It's a lot better. Thanks.
---
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
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17297#discussion_r107044660
--- Diff: core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala
---
@@ -929,12 +946,22 @@ class DAGScheduler
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17297#discussion_r107044272
--- Diff: core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala
---
@@ -803,6 +810,16 @@ class DAGScheduler(
stageIdToStage.get
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17297#discussion_r107040190
--- Diff: core/src/main/scala/org/apache/spark/MapOutputTracker.scala ---
@@ -418,6 +424,15 @@ private[spark] class MapOutputTrackerMaster(conf
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17297#discussion_r107018874
--- Diff: core/src/main/scala/org/apache/spark/MapOutputTracker.scala ---
@@ -378,15 +382,17 @@ private[spark] class MapOutputTrackerMaster(conf
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17297#discussion_r107018555
--- Diff: core/src/main/scala/org/apache/spark/MapOutputTracker.scala ---
@@ -378,15 +382,17 @@ private[spark] class MapOutputTrackerMaster(conf
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/17297#discussion_r107017201
--- Diff: core/src/main/scala/org/apache/spark/scheduler/DAGScheduler.scala
---
@@ -1265,64 +1280,11 @@ class DAGScheduler(
val
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17357
Please change the title of this PR. "Fixed foo" is nearly useless when
scanning the commit log in the future since it doesn't tell us anything about
either the nature of t
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17113
@squito Correct, we really only try to kill running tasks currently on job
failure (and if the config setting allows it); but there is the long-standing
"TODO: Cancel running tasks in the
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17113
@tgravescs At the config level, it is spark.job.interruptOnCancel or
SparkContext.SPARK_JOB_INTERRUPT_ON_CANCEL, which then gets passed around as a
boolean -- e.g. shouldInterruptThread
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17113
@mridulm Correct, turning task interruption on by default is not so much a
matter of Spark itself handling it well as it is a possible (though not
completely known) issue with lower layer
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17113
> Spark does immediately abort the stage but it doesn't kill the running
tasks
Whether running tasks are interrupted on stage abort or not depends on the
state of a config bool
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17113
"Current Spark's blacklist mechanism": please be more precise. The most
recent released version of Spark, 2.1.0, does not include a lot of recent
changes to blacklisting (mos
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17088
Even if I completely agreed that removing all of the shuffle files on a
host was the correct design choice, I'd still be hesitant to merge this right
now. That is simply because we have
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17045
thanks
---
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
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/17045
Please avoid using "fix" as the description in a PR -- it doesn't tell us
anything substantive about the nature of the problem or its resolution, so any
future reviewing of commi
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16905
Thanks, Shane & Kay!
---
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
ena
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16905
If Jenkins is listening to me, that should have allowed you to trigger test
for this PR.
test this please
---
If your project is set up for it, you can reply to this email and have
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16905
ok to test
---
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
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16620
LGTM
---
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
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/12524
@JoshRosen I haven't tried to walk through the logs in your JIRA comment,
but it wouldn't surprise me at all if this is the same issue that we've been
working through in https://github.com
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/15009#discussion_r100950587
--- Diff: core/src/main/scala/org/apache/spark/deploy/SparkSubmit.scala ---
@@ -719,7 +719,23 @@ object SparkSubmit extends CommandLineUtils
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/16905#discussion_r100836419
--- Diff:
core/src/main/scala/org/apache/spark/scheduler/TaskSchedulerImpl.scala ---
@@ -130,15 +130,17 @@ private[spark] class TaskSchedulerImpl
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/16905#discussion_r100834970
--- Diff: core/src/main/scala/org/apache/spark/scheduler/Pool.scala ---
@@ -37,25 +37,22 @@ private[spark] class Pool(
val schedulableQueue
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16905
@srowen These refactorings of unnecessary vars to vals is something that
we've noted in the discussions of a few other PRs as something that could and
probably should be done in a separate PR
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16620
Thanks for all the investigation and the write up, @kayousterhout This
makes good sense to me, and should take us a long way toward both fixing the
immediate bug and improving the code. We
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16876
You're welcome -- but do be aware that I'm going to be extremely busy with
non-Spark stuff for at least the next week, so for awhile my Spark code reviews
are likely to be more cursory than
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16876
Makes good sense to me.
---
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
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16620
@kayousterhout yes, I also looked at duplicating `stage.pendingPartitions
-= task.partitionId`. I could live with that.
---
If your project is set up for it, you can reply to this email
Github user markhamstra commented on a diff in the pull request:
https://github.com/apache/spark/pull/16813#discussion_r99964246
--- Diff:
core/src/main/scala/org/apache/spark/scheduler/SchedulableBuilder.scala ---
@@ -69,60 +72,81 @@ private[spark] class FairSchedulableBuilder
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16620
@kayousterhout don't overestimate my enthusiasm for my own suggestion. I'm
really just thinking aloud in search of a solution, and I agree with you that
the TaskSetManager and DAGScheduler
Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/16620
The way that I am thinking about this right now is that @kayousterhout is
on the right track with the early return at
https://github.com/apache/spark/blob/master/core/src/main/scala/org/apache
1 - 100 of 679 matches
Mail list logo
