SEZ9 commented on PR #12710: URL: https://github.com/apache/seatunnel/pull/12710#issuecomment-6378815473
Thanks for keeping this current. Since `96069fda` only merges `dev` on top of `f7ee365c` and the PR-owned diff is unchanged, my earlier points still apply; here is where each stands. **PR12710-F1 / PR12710-F2 (master/worker shutdown path)** – Good to see `terminationGracePeriodSeconds` now exposed in `values.yaml` for master and worker (default 30, rendered only when non-zero). That covers the grace-period half. The remaining concern is what the JVM does once SIGTERM reaches it: without a `hazelcast.shutdownhook.policy` setting the Hazelcast hook runs `TERMINATE`, and `SeaTunnelServer.shutdown` does not consult the terminate flag, so the node still tears down abruptly rather than performing the clean stop the PR description describes. Remaining asks: - Either set `hazelcast.shutdownhook.policy` in the chart to a graceful mode, or document why `TERMINATE` is intentional. - Clarify in the PR description what "clean stop" means here – "JVM exits within the grace period via its shutdown hook" vs. "jobs are drained/checkpointed before exit". If it is the former, please say so explicitly so users do not expect the latter. - If you have observed shutdown timings, it would help to note whether the default `30` is enough for the shutdown hook to complete on a typical node. **PR12710-F3 (docs)** – The en/zh docs now show the exec form and describe the SIGTERM path, which is the right direction. Please double-check that the Kubernetes graceful-shutdown section no longer presents the `preStop` + `stop-seatunnel-cluster.sh` hook as the primary way to get a clean stop, or, if that hook is still recommended for job draining, that the text explains how it relates to the new SIGTERM path so the two are not read as alternatives. Once the shutdown-hook policy question is settled and the docs wording matches the actual behaviour, I'm happy to take another look. <!-- streview-comment:1988 --> -- 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]
