ricky2129 commented on PR #12710:
URL: https://github.com/apache/seatunnel/pull/12710#issuecomment-6106793805
Thanks @SEZ9 for the careful re-check. Pushed an update addressing all three
points:
**Issue 1 / Issue 2 (TERMINATE semantics, no grace period knob)**
- Agreed: with the default `TERMINATE` policy, and
`SeaTunnelServer.shutdown` ignoring the `terminate` flag, this gives prompt
member removal and a fast exit, not a graceful job stop. Running tasks still
recover from their last checkpoint. I reworded the description so it no longer
promises a clean job stop.
- Added `master.terminationGracePeriodSeconds` and
`worker.terminationGracePeriodSeconds` to `values.yaml` and both Deployment
templates. The default is 30, the Kubernetes default, so nothing changes unless
it is set.
- Documented that `hazelcast.graceful.shutdown.max.wait` must stay below
`terminationGracePeriodSeconds` when `GRACEFUL` is used.
- I kept the default shutdown policy and did not add a chart value for it,
since `-Dhazelcast.shutdownhook.policy` is already settable through the JVM
options. Changing the default seems like a separate discussion.
**Issue 3 (docs)**
- The docker-compose examples in `docs/en` and `docs/zh` `docker.md` now use
the exec form `["/opt/seatunnel/bin/seatunnel-cluster.sh", "-r", "master"]`.
- The "Health Check and Graceful Shutdown" sections of
`hybrid-cluster-mode.md` and `separated-cluster-mode.md` (en/zh) now note:
- the container command must call the script directly, not through
`/bin/sh -c`;
- what `TERMINATE` and `GRACEFUL` do on SIGTERM;
- the relationship between `max.wait` and the grace period.
- The user-facing change is listed in the PR description, including that
`/bin/sh -c` overrides of `master.command` / `worker.command` need updating.
I also added
`SeaTunnelClusterScriptTest#testClusterScriptExecsServerJvmInForeground`, as
suggested in the earlier review, so a removed `exec` turns CI red. CI on my
fork was not triggering; that is fixed, and this push should produce a Build
run.
--
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]
