[FEATURE] Support timeout at `PlanOnlyMode`
- Dominant language
- Scala
- Stars
- 2.4k
- Forks
- 1k
- PR merge metrics
- No merged PRs in 30d
Description
### Code of Conduct
- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)
### Search before asking
- [x] I have searched in the [issues](https://github.com/apache/kyuubi/issues?q=is%3Aissue) and found no similar issues.
### Describe the feature
Currently, when the system runs in PlanOnlyMode (i.e., only parsing and analyzing SQL without actual execution), some complex SQL statements can cause the logical plan analysis phase to take a very long time, even though no physical execution is triggered.
In extreme cases, Catalyst optimization may consume very high CPU and memory resources during this phase.
I hope the operation can fail fast after a configurable timeout, so that plan analysis does not block the system for an excessive amount of time.
### Motivation
Make the statement in PlanOnly mode can timeout.
### Describe the solution
Support timeout at`PlanOnlyStatement`.
Make `runInternal` run in another thread, then we can cancel it. This differs from the current implementation of other `ExecuteStatement` methods, since the `PlanOnlyStatement` can only be cancel by interrupt.
As a long term solution, maybe we can implement a unified timeout monitor at the Engine Operation level. When the timeout is triggered, it uniformly cancels the future of the operation.
### Additional context
_No response_
### Are you willing to submit PR?
- [x] Yes. I would be willing to submit a PR with guidance from the Kyuubi community to improve.
- [x] No. I cannot submit a PR at this time.
Contributor guide
Research direction
Start at PlanOnlyStatement.runInternal and trace how current ExecuteStatement methods handle timeouts and cancellation. Determine how a configurable timeout should interrupt plan analysis, then verify that an overlong PlanOnly operation fails promptly without affecting other operations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala, spark
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100