apache / apache/kyuubi

[FEATURE] Support timeout at `PlanOnlyMode`

Open
#7,323 0 comments 0 reactions 0 assignees View on GitHub
kind:feature priority:major
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.