Github user JoshRosen commented on a diff in the pull request:
https://github.com/apache/spark/pull/10705#discussion_r53727828
--- Diff: core/src/main/scala/org/apache/spark/storage/BlockManager.scala
---
@@ -805,13 +814,12 @@ private[spark] class BlockManager(
}
}
} finally {
- // If we failed in putting the block to memory/disk, notify other
possible readers
- // that it has failed, and then remove it from the block info map.
- if (!marked) {
- // Note that the remove must happen before markFailure otherwise
another thread
- // could've inserted a new BlockInfo before we remove it.
- blockInfo.remove(blockId)
- putBlockInfo.markFailure()
+ if (!blockWasSuccessfullyStored) {
+ // Guard against the fact that MemoryStore might have already
removed the block if the
+ // put() failed and the block could not be dropped to disk.
+ if (blockInfoManager.lockForWriting(blockId, blocking =
false).isDefined) {
--- End diff --
I'm addressing this in a followup patch right now. The problem was that
certain logic for freeing block infos was previously baked into
`blockManager.dropFromMemory`, which is both called directly from the memory
store and from block manager internal methods. In some cases we want that
method to delete block infos and in other cases we don't, so I'm refactoring to
move that deletion logic elsewhere so we don't have this confusing block.
---
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.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
