wangzhigang1999 opened a new issue, #7120: URL: https://github.com/apache/kyuubi/issues/7120
### 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 This feature introduces a new, configurable, and highly efficient system for managing operation timeouts. It allows administrators to switch between the traditional "one-thread-per-operation" model and a new, scalable "shared-thread-pool" model. This provides crucial flexibility and control over how timeout-related resources are managed within the Kyuubi server, directly impacting its performance and stability under load. ### Motivation The current timeout mechanism, which creates a new thread for every single operation, does not scale well in production environments with high concurrency. This design leads to several critical issues: 1. **Excessive Resource Consumption**: High thread counts consume significant memory and kernel resources, putting pressure on the server. 2. **Performance Degradation**: Increased context-switching overhead from too many threads can degrade overall server performance. A more scalable and resource-efficient solution is necessary to ensure Kyuubi remains robust, performant, and reliable under heavy workloads. ### Describe the solution The solution involves a comprehensive refactoring of the timeout management system: 1. **Introduce a `TimeoutExecutor` Trait**: Create a new abstraction (`trait`) to define a contract for different timeout execution strategies. 2. **Implement Two Concrete Strategies**: * `PerOperationTimeoutExecutor`: An implementation that encapsulates the existing logic (one thread per operation) to ensure full backward compatibility. * `ThreadPoolTimeoutExecutor`: A new, more efficient implementation that uses a single, shared `ScheduledThreadPoolExecutor` to manage all timeout tasks. 3. **Create a `TimeoutExecutorFactory`**: A factory object responsible for creating the appropriate executor instance based on Kyuubi's configuration. This factory will manage the singleton instance of the `ThreadPoolTimeoutExecutor`. 4. **Add New Configuration Options**: * `kyuubi.operation.timeout.executor.type`: A new property to allow users to select either `per-operation` (default) or `thread-pool`. * `kyuubi.operation.timeout.pool.size`: To configure the core size of the shared thread pool. * `kyuubi.operation.timeout.pool.keepalive.time`: To configure the keep-alive time for idle threads in the pool. 5. **Integrate and Manage Lifecycle**: * Refactor `AbstractOperation` to use the new `TimeoutExecutorFactory` to obtain an executor. * Ensure the lifecycle of the shared `ThreadPoolTimeoutExecutor` is correctly managed by tying its `shutdown()` method to the `SessionManager`'s stop sequence, preventing resource leaks. ### 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. - [ ] No. I cannot submit a PR at this time. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@kyuubi.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@kyuubi.apache.org For additional commands, e-mail: notifications-h...@kyuubi.apache.org
