Github user squito commented on a diff in the pull request:
https://github.com/apache/spark/pull/6423#discussion_r31962636
--- Diff:
core/src/main/scala/org/apache/spark/storage/ShuffleBlockFetcherIterator.scala
---
@@ -298,11 +294,9 @@ final class ShuffleBlockFetcherIterator(
// not exist, SPARK-4085). In that case, we should propagate the
right exception so
// the scheduler gets a FetchFailedException.
Try(buf.createInputStream()).map { is0 =>
- val is = blockManager.wrapForCompression(blockId, is0)
- val iter =
serializerInstance.deserializeStream(is).asKeyValueIterator
- CompletionIterator[Any, Iterator[Any]](iter, {
- // Once the iterator is exhausted, release the buffer and set
currentResult to null
- // so we don't release it again in cleanup.
+ // Once the single-element (is0) iterator is exhausted, release
the buffer so that we
+ // don't release it again in cleanup.
+ CompletionIterator[InputStream,
Iterator[InputStream]](Iterator(is0), {
--- End diff --
sorry jumping in a little late here -- but I think the caller doesn't
*have* to call `close()`, because its already getting called in the a task
completion listener
[here](https://github.com/apache/spark/blob/master/core/src/main/scala/org/apache/spark/storage/ShuffleBlockFetcherIterator.scala#L252),
which is more robust. It doesn't hurt for the user to call it anyway (another
reason why `close` needs to be idempotent), but otherwise i think its really
important that this close gets called by the framework, or else its really easy
to have a leak.
(all that said, it looks like its still fine after the patch in its current
form.)
---
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]
