-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-3591][YARN]fire and forget for YARN cluster mode #5297
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
Changes from all commits
0cbdce8
19706c0
e1a4013
ba9b22b
f0bc54f
be1cc2e
fea390d
16c90a8
c76d232
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -196,6 +196,15 @@ Most of the configs are the same for Spark on YARN as for other deployment modes | |
| It should be no larger than the global number of max attempts in the YARN configuration. | ||
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td><code>spark.yarn.submit.waitAppCompletion</code></td> | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is the purpose of making this configurable to provide backward compatibility? I wonder if the new behavior should just be the default; I can't imagine someone actually going out of her way to set this to false explicitly. On the other hand people may rely on the existing behavior to detect when the application has finished, but this is somewhat of an arbitrary behavior of Spark for the user to rely on. What do others think?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah the intention was for backwards compatibility. As you say if they are relying on the current behavior in other scripting it would now break.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My opinion is that it would be fairly reasonable for users to have relied on the current behavior, so we shouldn't break it. |
||
| <td>true</td> | ||
| <td> | ||
| In YARN cluster mode, controls whether the client waits to exit until the application completes. | ||
| If set to true, the client process will stay alive reporting the application's status. | ||
| Otherwise, the client process will exit after submission. | ||
| </td> | ||
| </tr> | ||
| </table> | ||
|
|
||
| # Launching Spark on YARN | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it looks like its missing a space between the failed and message but then again it wasn't here before. What does this message look like?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The space is actually added in the map operation:
.map { ": " + _ }I hadn't check what the message looks like before. Think it is not a problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, it should be fine