Skip to content

[KYUUBI #7776][HA] Stop gracefully without waiting on sessions of a stopped session manager - #7777

Open
afterincomparableyum wants to merge 2 commits into
apache:masterfrom
afterincomparableyum:fix-graceful-stop-stopped-session-manager
Open

afterincomparableyum wants to merge 2 commits into
apache:masterfrom
afterincomparableyum:fix-graceful-stop-stopped-session-manager

Conversation

@afterincomparableyum

@afterincomparableyum afterincomparableyum commented Oct 12, 2026 •

Copy link
Copy Markdown

Why are the changes needed?

Close #7776.

ServiceDiscovery.stopGracefully waits while the active user session count is positive. Once the session manager has stopped, its idle-session timeout checker is shut down, so sessions left by disconnected clients (common with kyuubi.session.close.on.disconnect=false) are never closed and the loop never ends. With etcd the loop runs on the non-daemon deregister-watcher-thread, so the engine JVM cannot exit after its SparkContext and backend have stopped, and the driver pod stays alive until deleted by hand.

This change stops waiting once the session manager is STOPPED, since no session can make progress at that point, and logs a warning with the number of sessions still open. #6790 re-reads the count inside the loop but does not cover this case.

How was this patch tested?

Added a case to DiscoveryClientTests that opens a session, stops the session manager, deletes the service node, and expects the service to stop. It runs in both the ZooKeeper and etcd suites.

build/mvn test -pl kyuubi-ha -am -Dtest=none \
  -DwildcardSuites=org.apache.kyuubi.ha.client.zookeeper.EmbeddedZookeeperDiscoveryClientSuite

All 12 tests pass. Without the ServiceDiscovery change, the new test never finishes and logs 1 connection(s) are active, delay shutdown every 10 seconds.

Was this patch assisted by generative AI tooling?

Claude Opus 5.5 was used to assist with debugging and triaging the issue.

Assisted-by: Claude Code with Claude Opus 5.5

…of a stopped session manager

ServiceDiscovery.stopGracefully waits while the active user session count
is positive. Once the session manager has stopped, its idle-session
timeout checker is shut down, so sessions left by disconnected clients are
never closed and the loop never ends. With etcd the loop runs on the
non-daemon deregister-watcher-thread, which keeps the engine JVM alive
after its SparkContext and backend have stopped.

Stop waiting once the session manager is STOPPED, and log a warning with
the number of sessions still open.
@afterincomparableyum

Copy link
Copy Markdown
Author

@pan3793 could you take another look when you have time please? Thank you!

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] Engine does not exit when graceful stop waits on sessions of a stopped session manager

2 participants