Github user mridulm commented on a diff in the pull request:
https://github.com/apache/spark/pull/1165#discussion_r14738178
--- Diff: core/src/main/scala/org/apache/spark/CacheManager.scala ---
@@ -142,10 +151,76 @@ private[spark] class CacheManager(blockManager:
BlockManager) extends Logging {
* to the BlockManager as an iterator and expect to read it back
later. This is because
* we may end up dropping a partition from memory store before
getting it back, e.g.
* when the entirety of the RDD does not fit in memory. */
- val elements = new ArrayBuffer[Any]
- elements ++= values
- updatedBlocks ++= blockManager.put(key, elements, storageLevel,
tellMaster = true)
- elements.iterator.asInstanceOf[Iterator[T]]
+
--- End diff --
If the case is, no matter which node in cluster, the iterator cant be
cached - then I concede your point : but this patch does not enforce that
assertion.
You are assuming that if it cant be cached on node1, it cant be cached in
any other nodeX in the cluster. The OOM might not be necessarily due to the
size of the iterator in question, but also due to other data hosted on that
node.
So this is not equivalent but a change in behaviour.
Also note that when we drop blocks from an rdd, we never do that for the
current rdd - just "earlier" rdd : here, we just dont cache the current
iterator at all.
Particularly for iterative algo's, dropping blocks from "earlier" RDD might
be fine - but not caching current can result in repeated recomputation down the
lineage : which can be prohibitively expensive (we are not talking in face of
failures btw - just normal computation).
---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
