xkrogen commented on code in PR #38832:
URL: https://github.com/apache/spark/pull/38832#discussion_r1038612370
##########
resource-managers/yarn/src/main/scala/org/apache/spark/deploy/yarn/ApplicationMaster.scala:
##########
@@ -240,6 +240,9 @@ private[spark] class ApplicationMaster(
logInfo("ApplicationAttemptId: " + appAttemptId)
+ // During shutdown, we may not be able to create an FileSystem object.
So, pre-create here.
+ val stagingDirPath = new Path(System.getenv("SPARK_YARN_STAGING_DIR"))
+ val stagingDirFs = stagingDirPath.getFileSystem(yarnConf)
Review Comment:
> Is it safe to hold on to the FS object like this in the hook?
I don't see why this would be an issue. It adds one additional reference to
the state required for the hook, but this is negligible. FS objects are already
globally cached, so in a typical case there is no new/additional FS instance
being held onto by the hook; just a reference to the same FS object which would
be used elsewhere throughout the driver. If `SPARK_YARN_STAGING_DIR` happens to
be on a different file system than everything else, you'll end up with an
additional FS reference, but most FS implementations (including HDFS)
initialize all of their external connections lazily (upon the time of the first
RPC) so you're just talking about a small amount of in-memory state.
> But that does not seem to be the case right now.
Can you elaborate @xinglin?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
