Skip to content

[SPARK-21067][SQL] Fix Thrift Server - CTAS fail with Unable to move source#25058

Closed
Deegue wants to merge 1 commit intoapache:masterfrom
Deegue:master-fix_thrift_file_system
Closed

[SPARK-21067][SQL] Fix Thrift Server - CTAS fail with Unable to move source#25058
Deegue wants to merge 1 commit intoapache:masterfrom
Deegue:master-fix_thrift_file_system

Conversation

@Deegue
Copy link
Contributor

@Deegue Deegue commented Jul 5, 2019

What changes were proposed in this pull request?

When we close a session of STS, FileSystem(cached by default) on HDFS will be closed.
Then if we do CTAS and trigger Hive.moveFile, DFSClient will do checkOpen and throw java.io.IOException: Filesystem closed.

So we add a Spark config spark.sql.thriftserver.hdfs.disable.cache to control whether disable the FileSystem connection cache of HDFS.

How was this patch tested?

Manually tested.

@jerryshao
Copy link
Contributor

This is a known issue (due to the design of Hadoop FileSystem interface), you can set hadoop configuration explicitly to disable cache either via Spark or via hadoop conf file. I don't think it is necessary to add another configuration. Besides this only works for HDFS.

@Deegue
Copy link
Contributor Author

Deegue commented Jul 6, 2019

This is a known issue (due to the design of Hadoop FileSystem interface), you can set hadoop configuration explicitly to disable cache either via Spark or via hadoop conf file. I don't think it is necessary to add another configuration. Besides this only works for HDFS.

Thanks for your review, what about change fs.hdfs.impl.disable.cache to fs.%s.impl.disable.cache?
This way or add docs to fix [SPARK-21067], I don't know which way is more appropriate.

@jerryshao
Copy link
Contributor

I don't think it is necessary to do some code changes for this, may be adding docs is enough.

@xy-xin
Copy link

xy-xin commented Jul 12, 2019

@jerryshao I don't know if I understand the problem correctly. I submitted a patch under that jira which is based on spark-2.3.2 several months ago. My understanding is that It is the working thread who created the FS. This FS client would be closed if the working thread closes. If we let the main thread create the FS, the problem could be resolved.

@jerryshao
Copy link
Contributor

Yes, you can carefully track which thread to create FS and guarantee the same thread to close FS, then this problem could be solved, but it is a little hard to track.

@AmplabJenkins
Copy link

Can one of the admins verify this patch?

@HyukjinKwon
Copy link
Member

doc fix seems arrived. Per #25058 (comment), I suspect we need a different approach. I am closing this due to inactivity for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants