Github user ksakellis commented on a diff in the pull request:
https://github.com/apache/spark/pull/4020#discussion_r23058543
--- Diff: core/src/main/scala/org/apache/spark/executor/TaskMetrics.scala
---
@@ -240,10 +284,18 @@ class ShuffleWriteMetrics extends Serializable {
/**
* Number of bytes written for the shuffle by this task
*/
- @volatile var shuffleBytesWritten: Long = _
-
+ @volatile private var _shuffleBytesWritten: Long = _
+ def shuffleBytesWritten = _shuffleBytesWritten
+ private[spark] def incShuffleBytesWritten(value: Long) =
_shuffleBytesWritten += value
+ private[spark] def decShuffleBytesWritten(value: Long) =
_shuffleBytesWritten -= value
+
/**
* Time the task spent blocking on writes to disk or buffer cache, in
nanoseconds
*/
- @volatile var shuffleWriteTime: Long = _
--- End diff --
Fair enough, but it is hard to guarantee that only one thread will
increment the value. We could mark the class as not thread safe by docs but it
might be a ticking time bomb. Is the overhead of AtomicLong that concerning to
risk concurrency issues down the line?
Speaking of shuffleMetrics, can we get rid of the array of
shuffleReadMetrics (depsShuffleReadMetrics) and the merge step in favor of
using AtomicLongs in ShuffleReadMetrics? That way the TaskMetrics can just
return the same threadsafe ShuffleReadMetrics to the tasks and there wouldn't
need to be a need to call updateShuffleReadMetrics periodically in the Executor
heartbeat code.
---
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]
