-
Notifications
You must be signed in to change notification settings - Fork 976
[KYUUBI #7290] Prevent engine session leak after Kyuubi session closed #7294
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
Conversation
…uubi session has been closed
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #7294 +/- ##
======================================
Coverage 0.00% 0.00%
======================================
Files 698 698
Lines 43636 43646 +10
Branches 5893 5894 +1
======================================
- Misses 43636 43646 +10 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
kyuubi-common/src/main/scala/org/apache/kyuubi/session/AbstractSession.scala
Show resolved
Hide resolved
|
the idea makes sense to me |
866126d to
f3e9098
Compare
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.
Pull request overview
This PR addresses a resource leak issue where an engine session could remain active after the Kyuubi session was closed, specifically when the Kyuubi session is closed during the engine session initialization process.
Key Changes:
- Added
isClosedmethod to the Session trait to track session closure state - Implemented the isClosed check in AbstractSession using a volatile boolean flag
- Added a check in KyuubiSessionImpl after engine session initialization to detect if the Kyuubi session was closed during initialization and throw an exception to trigger cleanup
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| kyuubi-common/src/main/scala/org/apache/kyuubi/session/Session.scala | Added isClosed method signature to the Session trait |
| kyuubi-common/src/main/scala/org/apache/kyuubi/session/AbstractSession.scala | Implemented isClosed method with a @volatile boolean flag and added idempotent close logic |
| kyuubi-server/src/main/scala/org/apache/kyuubi/session/KyuubiSessionImpl.scala | Added isClosed check after engine session opening to prevent resource leak when Kyuubi session is closed during engine initialization |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
kyuubi-server/src/main/scala/org/apache/kyuubi/session/KyuubiSessionImpl.scala
Outdated
Show resolved
Hide resolved
| if (isClosed) { | ||
| throw KyuubiSQLException(s"KyuubiSession $handle has been closed") | ||
| } |
Copilot
AI
Jan 3, 2026
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.
This critical race condition fix lacks automated test coverage. Consider adding a test that simulates closing a Kyuubi session while the engine session is being initialized to verify that the engine session is properly cleaned up. This could be done by using a mock or by introducing a delay in the engine session opening process during the test.
f3e9098 to
d3c8608
Compare
kyuubi-server/src/main/scala/org/apache/kyuubi/session/KyuubiSessionImpl.scala
Show resolved
Hide resolved
kyuubi-server/src/main/scala/org/apache/kyuubi/session/KyuubiSessionImpl.scala
Outdated
Show resolved
Hide resolved
|
Hi @pan3793, please help re-run the timeout test case. Thanks! |
### Why are the changes needed? close #7290 When we close a kyuubi session, if the engine session(thrift client) has not initialized, then the kyuubi session will be closed, but the engine session might be alive, then will result in a resource leak. ### How was this patch tested? Can be tested by when the engine pod is pending, and then kill the jdbc client, the driver pod should be killed after initialized. ### Was this patch authored or co-authored using generative AI tooling? NO Closes #7294 from ruanwenjun/dev_wenjun_fix7290. Closes #7290 142a210 [ruanwenjun] make sure the client closed 9745206 [ruanwenjun] set shouldRetry to false d3c8608 [ruanwenjun] remove unused comment 866126d [ruanwenjun] If the session already closed, then return 3b2ee39 [ruanwenjun] [KYUUBI #7290] Fix the engine session might still alive when kyuubi session has been closed Authored-by: ruanwenjun <[email protected]> Signed-off-by: Cheng Pan <[email protected]> (cherry picked from commit 8bed9de) Signed-off-by: Cheng Pan <[email protected]>
### Why are the changes needed? close #7290 When we close a kyuubi session, if the engine session(thrift client) has not initialized, then the kyuubi session will be closed, but the engine session might be alive, then will result in a resource leak. ### How was this patch tested? Can be tested by when the engine pod is pending, and then kill the jdbc client, the driver pod should be killed after initialized. ### Was this patch authored or co-authored using generative AI tooling? NO Closes #7294 from ruanwenjun/dev_wenjun_fix7290. Closes #7290 142a210 [ruanwenjun] make sure the client closed 9745206 [ruanwenjun] set shouldRetry to false d3c8608 [ruanwenjun] remove unused comment 866126d [ruanwenjun] If the session already closed, then return 3b2ee39 [ruanwenjun] [KYUUBI #7290] Fix the engine session might still alive when kyuubi session has been closed Authored-by: ruanwenjun <[email protected]> Signed-off-by: Cheng Pan <[email protected]> (cherry picked from commit 8bed9de) Signed-off-by: Cheng Pan <[email protected]>
|
thanks, merged to master/1.11.1/1.10.4 |
Why are the changes needed?
close #7290
When we close a kyuubi session, if the engine session(thrift client) has not initialized, then the kyuubi session will be closed, but the engine session might be alive, then will result in a resource leak.
How was this patch tested?
Can be tested by when the engine pod is pending, and then kill the jdbc client, the driver pod should be killed after initialized, but not.
Was this patch authored or co-authored using generative AI tooling?
NO