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

[BEAM-7696] Prepare files to stage also in local master of spark runner. #9019

Merged
merged 1 commit into from Jul 23, 2019

Conversation

yanlin-Lynn
Copy link
Contributor

The result of PipelineResources.detectClassPathResourcesToStage may contain directory, which will cause exception, when running unit test of SparkRunner. See the attached picture file in BEAM-7696 for detail of exception in such case. Even though the exception does not make SparkContext stop when running in local master, it's better not to include non-jars files in classpath.


Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

  • Choose reviewer(s) and mention them in a comment (R: @username).
  • Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
  • If this contribution is large, please file an Apache Individual Contributor License Agreement.

Post-Commit Tests Status (on master branch)

Lang SDK Apex Dataflow Flink Gearpump Samza Spark
Go Build Status --- --- Build Status --- --- Build Status
Java Build Status Build Status Build Status Build Status
Build Status
Build Status
Build Status Build Status Build Status
Build Status
Python Build Status
Build Status
--- Build Status
Build Status
Build Status --- --- Build Status

Pre-Commit Tests Status (on master branch)

--- Java Python Go Website
Non-portable Build Status Build Status Build Status Build Status
Portable --- Build Status --- ---

See .test-infra/jenkins/README for trigger phrase, status and link of all Jenkins jobs.

@iemejia
Copy link
Member

iemejia commented Jul 15, 2019

Run Spark ValidatesRunner

@iemejia
Copy link
Member

iemejia commented Jul 15, 2019

Run Java Spark PortableValidatesRunner Batch

@iemejia iemejia self-requested a review July 15, 2019 13:15
@iemejia
Copy link
Member

iemejia commented Jul 15, 2019

R: @ibzib
Kyle can you please help me with this review. Thx.

@iemejia iemejia changed the title [BEAM-7696]prepare files to stage also in local master of spark runner. [BEAM-7696] Prepare files to stage also in local master of spark runner. Jul 15, 2019
Copy link
Contributor

@ibzib ibzib left a comment

Choose a reason for hiding this comment

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

Hi Yanlin, thanks for the PR.

Since PipelineResources.java is in the core-construction package, it is shared by all Beam runners. While adding directories just causes Spark to throw an exception, directories might be acceptable or even desirable on different runners (I don't actually know--just being cautious here). So it would be better to limit this change to the runners.spark package (maybe by calling PipelineResources.detectClassPathResourcesToStage as-is, then removing directories in SparkPipelineOptions.prepareFilesToStage).

@yanlin-Lynn
Copy link
Contributor Author

yanlin-Lynn commented Jul 18, 2019

Hi Yanlin, thanks for the PR.

Since PipelineResources.java is in the core-construction package, it is shared by all Beam runners. While adding directories just causes Spark to throw an exception, directories might be acceptable or even desirable on different runners (I don't actually know--just being cautious here). So it would be better to limit this change to the runners.spark package (maybe by calling PipelineResources.detectClassPathResourcesToStage as-is, then removing directories in SparkPipelineOptions.prepareFilesToStage).

Yeah. I aggre with you. And in this patch, I do exclude directories.

@ibzib
Copy link
Contributor

ibzib commented Jul 18, 2019

I suggest changing only the Spark runner code. That way, we can exclude nonexistent files and existing directories, without having to worry about the other runners. (While it may seem strange that other runners would ever use paths to resources that do not exist at the time of calling detectClassPathResourcesToStage, it's hard to prove that it couldn't happen, so I think it's better to just limit the scope of this change.)

@yanlin-Lynn
Copy link
Contributor Author

yanlin-Lynn commented Jul 19, 2019

I suggest changing only the Spark runner code. That way, we can exclude nonexistent files and existing directories, without having to worry about the other runners. (While it may seem strange that other runners would ever use paths to resources that do not exist at the time of calling detectClassPathResourcesToStage, it's hard to prove that it couldn't happen, so I think it's better to just limit the scope of this change.)

OK. This is a safer way.

@iemejia
Copy link
Member

iemejia commented Jul 22, 2019

Run Spark ValidatesRunner

List<String> filesToStage =
options.getFilesToStage().stream()
.map(File::new)
.filter(File::exists)
Copy link
Contributor

Choose a reason for hiding this comment

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

What about directories?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The PipelineResources.prepareFilesForStaging will package directories into jar file. That's why call this method before create a SparkContext.

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay, I missed that.

It looks like prepareFilesForStaging also throws IllegalStateException if a file doesn't exist. It might be better to throw the exception to alert the user, rather than silently filtering out a missing dependency and have an error show up later.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, I guess there are always nonexistent files. Weird. Well, this is fine then.

Copy link
Contributor

@ibzib ibzib left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@iemejia iemejia left a comment

Choose a reason for hiding this comment

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

LGTM

@iemejia iemejia merged commit 2ae62ff into apache:master Jul 23, 2019
@iemejia
Copy link
Member

iemejia commented Jul 23, 2019

Thanks @yanlin-Lynn !

@yanlin-Lynn yanlin-Lynn deleted the detect_classpath branch July 24, 2019 02:55
@lukecwik
Copy link
Member

lukecwik commented Aug 8, 2019

I suggest that we re-use the code in Dataflow and to automatically convert directory classpath entries into jars:

It will likely require some refactoring to make it available to more runners.

@yanlin-Lynn
Copy link
Contributor Author

I suggest that we re-use the code in Dataflow and to automatically convert directory classpath entries into jars:

It will likely require some refactoring to make it available to more runners.

Currently, there exist detectClassPathResourcesToStage and prepareFilesForStaging in PipelineResources. Do you mean to do the packaging of directories inside detectClassPathResourcesToStage, so no need to call prepareFilesForStaging manually?

@lukecwik
Copy link
Member

I suggest that we re-use the code in Dataflow and to automatically convert directory classpath entries into jars:

It will likely require some refactoring to make it available to more runners.

Currently, there exist detectClassPathResourcesToStage and prepareFilesForStaging in PipelineResources. Do you mean to do the packaging of directories inside detectClassPathResourcesToStage, so no need to call prepareFilesForStaging manually?

I thought the issue was that the SparkRunner couldn't handle directories but I misread the conversation above and its related to non-existent files so my comment doesn't make any sense and no change is needed/wanted.

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.

None yet

4 participants