ruanwenjun commented on code in PR #17909:
URL:
https://github.com/apache/dolphinscheduler/pull/17909#discussion_r2745737244
##########
dolphinscheduler-task-plugin/dolphinscheduler-task-flink/src/main/java/org/apache/dolphinscheduler/plugin/task/flink/FlinkParameters.java:
##########
@@ -114,6 +114,21 @@ public class FlinkParameters extends AbstractParameters {
*/
private String rawScript;
+ /**
+ * Shutdown on attached exit (-sae parameter)
+ *
+ * <p>When enabled, Flink CLI will attempt to shutdown the cluster when
the CLI
+ * terminates abruptly. This is only suitable for attached mode
(CLUSTER/LOCAL).
+ *
+ * <p>For APPLICATION mode, this should typically be disabled as the job
runs
+ * in detached mode on YARN.
+ *
+ * <p>Default: false (disabled for safety)
+ *
+ * @see FlinkArgsUtils#buildRunCommandLine
+ */
+ private Boolean shutdownOnAttachedExit;
Review Comment:
@chris-fast What I’m trying to say is that we shouldn’t break compatibility
here. Regardless of how we deal with the failover issue in the future, using
-sea is not a bad thing.
Adapting the upper layer just to work around a bug in a specific version of
a lower-level component isn’t a sustainable approach. If different versions of
the lower layer each have their own issues, does that mean the upper layer
needs to keep adding special handling for all of them? That would make the
system increasingly complex and fragile.
Also, I don’t quite understand the statement that “it’s not really a Flink
bug.” From my perspective, the unexpected behavior originates from Flink’s
side, so it’s hard to see why it wouldn’t be considered a bug there.
Introducing this parameter makes it hard to explain to users under what
circumstances they should enable `shutdownOnAttachedExit`. If I am the user, I
will ask "If this parameter is turned off, will the process not exit? Under
what circumstances would we want the process to stay alive instead of exiting".
--
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]
