-
Notifications
You must be signed in to change notification settings - Fork 28k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SPARK-12887] Do not expose var's in TaskMetrics #10815
Conversation
Note: there's one remaining place, which is JsonProtocol.
JsonProtocol remains the only place where we still call set on each of the *Metrics classes.
This commit collapsed 10 methods into 2. The 8 that were inlined were only used in 1 place each, and the body of each was quite small. The additional level of abstraction did not add much value and made the code verbose.
This is going to conflict with #10776, so I'd like to merge my patch first. |
…etrics Conflicts: core/src/main/scala/org/apache/spark/CacheManager.scala core/src/main/scala/org/apache/spark/memory/StorageMemoryPool.scala core/src/test/scala/org/apache/spark/CacheManagerSuite.scala
3948a5b
to
e99b9af
Compare
retest this please |
// that one. Otherwise, if the read method is different from the one previously seen by | ||
// this task, we return a new dummy one to avoid clobbering the values of the old metrics. | ||
// In the future we should try to store input metrics from all different read methods at | ||
// the same time (SPARK-5225). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, that's unfortunate. Since it's a pre-existing problem, it's fine to not fix it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before, I guess we'd unconditionally overwrite so we might handle it wrong even for the same read method case? This looks good to me, just curious RE: whether this fixed another bug.
Test build #49615 has finished for PR 10815 at commit
|
} | ||
|
||
self.context.runJob(self, writeToFile) | ||
writer.commitJob() | ||
} | ||
|
||
private def initHadoopOutputMetrics(context: TaskContext): (OutputMetrics, Option[() => Long]) = { | ||
// TODO: these don't seem like the right abstractions. | ||
// We should abstract the duplicate code in a less awkward way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed; this is kinda messy.
I'm all finished with my review pass. I have two main pieces of feedback:
Aside from those things, this looks good. |
2e84e30
to
3e38670
Compare
3e38670
to
c04b5df
Compare
Test build #49622 has finished for PR 10815 at commit
|
Test build #49627 has finished for PR 10815 at commit
|
Test build #49642 has finished for PR 10815 at commit
|
Test build #49646 has finished for PR 10815 at commit
|
Okay, so it turns out that I was wrong about the
becomes
Do you mind rolling back the changes due to that? Sorry about that. |
Test build #49632 has finished for PR 10815 at commit
|
retest this please |
Uh oh, this merge-conflicted. I'm going to try to fix the conflicts and will submit a PR against your PR. You can on-the-go merge-button it, then I'll retest to get this in. |
Test build #49657 has finished for PR 10815 at commit
|
Fixed the conflicts at andrewor14#3 |
Fix merge conflicts in get-or-create-metrics PR
retest this please |
LGTM, so feel free to merge. |
Test build #49665 has finished for PR 10815 at commit
|
Jenkins retest this please |
Test build #49687 has finished for PR 10815 at commit
|
Merged into master. |
This is a step in implementing SPARK-10620, which migrates TaskMetrics to accumulators.
TaskMetrics has a bunch of var's, some are fully public, some are
private[spark]
. This is bad coding style that makes it easy to accidentally overwrite previously set metrics. This has happened a few times in the past and caused bugs that were difficult to debug.Instead, we should have get-or-create semantics, which are more readily understandable. This makes sense in the case of TaskMetrics because these are just aggregated metrics that we want to collect throughout the task, so it doesn't matter who's incrementing them.
Parent PR: #10717