Skip to content
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-19794 Release HDFS Client after read/write checkpoint #17135

Closed
wants to merge 1 commit into from

Conversation

darionyaphet
Copy link

What changes were proposed in this pull request?

Close HDFS client and streams after reading and writing from HDFS .

How was this patch tested?

(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

Please review http://spark.apache.org/contributing.html before opening a pull request.

@srowen
Copy link
Member

srowen commented Mar 2, 2017

I get the idea, but I'm not sure any of these are valid

logInfo(s"Final output path $finalOutputPath already exists; not overwriting it")
if (!fs.delete(tempOutputPath, false)) {
logWarning(s"Error deleting ${tempOutputPath}")
try {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that this doesn't encompass the span of usage for fs -- better to just call fs.close() at the end and not worry about manually closing in an error case? or expand the try-finally?

Actually, I am not sure we are supposed to call FileSystem.close() because they are shared instances, cached and reused across the whole application.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed with @srowen , FileSystem is a cached object, closing it means removed it from cache. I don't think we need to call this explicitly. Because by default it is designed to be shared.

@@ -216,6 +221,8 @@ private[spark] object ReliableCheckpointRDD extends Logging {
serializeStream.writeObject(partitioner)
} {
serializeStream.close()
fileOutputStream.close()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto, this is OK if serializeStream.close() doesn't actually close the underlying stream (?) but not sure about the next line.

@@ -279,8 +287,13 @@ private[spark] object ReliableCheckpointRDD extends Logging {

// Register an on-task-completion callback to close the input stream.
context.addTaskCompletionListener(context => deserializeStream.close())

deserializeStream.asIterator.asInstanceOf[Iterator[T]]
Utils.tryWithSafeFinally {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you can close it here, right? you're returning an iterator on the stream

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code will introduce issue, deserializaStream should be called after finished, the code here will close this stream prematurely.

Also please look at L289, it already takes care of close after the task is finished.

@SparkQA
Copy link

SparkQA commented Mar 2, 2017

Test build #3592 has finished for PR 17135 at commit 60754bd.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@zsxwing
Copy link
Member

zsxwing commented Mar 3, 2017

I remember FileSystem will be cached internally by default. Closing it probably will introduce some performance regression. Did you see any case that FileSystem cache doesn't work properly?

@srowen
Copy link
Member

srowen commented Mar 3, 2017

Yes this is substantially not something we can merge, so let's close this.

@vanzin
Copy link
Contributor

vanzin commented Mar 3, 2017

It's not just a matter of performance regression - it will brake any other code that has references to the file system being closed. -1.

srowen added a commit to srowen/spark that referenced this pull request Mar 22, 2017
@srowen srowen mentioned this pull request Mar 22, 2017
@asfgit asfgit closed this in b70c03a Mar 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants