Skip to content

Conversation

@andrewor14
Copy link
Contributor

In SparkSubmitDriverBootstrapper, we wait for the parent process to send us an EOF before finishing the application. This is applicable for the PySpark shell because we terminate the application the same way. However if we run a python application, for instance, the JVM actually never exits unless it receives a manual EOF from the user. This is causing a few tests to timeout.

We only need to do this for the PySpark shell because Spark submit runs as a python subprocess only in this case. Thus, the normal Spark shell doesn't need to go through this case even though it is also a REPL.

Thanks @davies for reporting this.

Otherwise the application simply won't exit unless we manually
send an EOF.
@SparkQA
Copy link

SparkQA commented Aug 28, 2014

QA tests have started for PR 2170 at commit 42963f5.

  • This patch merges cleanly.

@andrewor14
Copy link
Contributor Author

Tested the shell and SparkPi in both Scala and Python locally on OSX and Windows. All subprocesses are confirmed to exit as expected.

@SparkQA
Copy link

SparkQA commented Aug 28, 2014

QA tests have finished for PR 2170 at commit 42963f5.

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

@andrewor14
Copy link
Contributor Author

Test failures are not related. Jenkins, retest this please.

@davies
Copy link
Contributor

davies commented Aug 28, 2014

The cases about SparkSubmit are flaky...

@SparkQA
Copy link

SparkQA commented Aug 28, 2014

QA tests have started for PR 2170 at commit 42963f5.

  • This patch merges cleanly.

@andrewor14
Copy link
Contributor Author

Yup, I'm looking into it...

@SparkQA
Copy link

SparkQA commented Aug 28, 2014

QA tests have finished for PR 2170 at commit 42963f5.

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

@pwendell
Copy link
Contributor

Okay thanks - I'll merge this.

asfgit pushed a commit that referenced this pull request Aug 28, 2014
In `SparkSubmitDriverBootstrapper`, we wait for the parent process to send us an `EOF` before finishing the application. This is applicable for the PySpark shell because we terminate the application the same way. However if we run a python application, for instance, the JVM actually never exits unless it receives a manual EOF from the user. This is causing a few tests to timeout.

We only need to do this for the PySpark shell because Spark submit runs as a python subprocess only in this case. Thus, the normal Spark shell doesn't need to go through this case even though it is also a REPL.

Thanks davies for reporting this.

Author: Andrew Or <[email protected]>

Closes #2170 from andrewor14/bootstrap-hotfix and squashes the following commits:

42963f5 [Andrew Or] Do not wait for EOF unless this is the pyspark shell
(cherry picked from commit dafe343)

Signed-off-by: Patrick Wendell <[email protected]>
@asfgit asfgit closed this in dafe343 Aug 28, 2014
@andrewor14 andrewor14 deleted the bootstrap-hotfix branch August 28, 2014 06:10
xiliu82 pushed a commit to xiliu82/spark that referenced this pull request Sep 4, 2014
In `SparkSubmitDriverBootstrapper`, we wait for the parent process to send us an `EOF` before finishing the application. This is applicable for the PySpark shell because we terminate the application the same way. However if we run a python application, for instance, the JVM actually never exits unless it receives a manual EOF from the user. This is causing a few tests to timeout.

We only need to do this for the PySpark shell because Spark submit runs as a python subprocess only in this case. Thus, the normal Spark shell doesn't need to go through this case even though it is also a REPL.

Thanks davies for reporting this.

Author: Andrew Or <[email protected]>

Closes apache#2170 from andrewor14/bootstrap-hotfix and squashes the following commits:

42963f5 [Andrew Or] Do not wait for EOF unless this is the pyspark shell
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.

4 participants