[Umbrella] Support to reconnect the JDBC connection
- 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) and found no similar issues.
### Describe the proposal
1. in engine side, do not terminate the session life cycle once receive the close session request, support fireoff, and wait the current statements finished(configurable)
2. when the connection to kyuubi gateway disconnect, close the session to engine(engine will hold the session lify cycle with timeout)
3. client holds the engine refId and sessionhandle, client can reopen the session to any kyuubi instance and connect to the original engine with engine refId.
4. when client get the status of operation with opHandle, if the operation not found in gateway, get the status from engine side as fallback
5. kyuubi client can persist the session information to external storage and can recover with that.
### Task list
TBD
### Are you willing to submit PR?
- [ ] Yes. I would be willing to submit a PR with guidance from the Kyuubi community to improve.
- [ ] No. I cannot submit a PR at this time.
Contributor guide
Research direction
The proposal covers engine-side session lifecycle, gateway disconnects, client-held engine references, operation status fallback, and persisted session recovery. Start by tracing those session and operation paths across the engine, gateway, and client; the task list is TBD, so the completion criteria and affected files are not yet defined.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala, spark
- Domain
- distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100