wangzhigang1999 opened a new pull request, #7121:
URL: https://github.com/apache/kyuubi/pull/7121
### Why are the changes needed?
The existing mechanism for handling operation timeouts in Kyuubi creates a
new `ScheduledExecutorService` with a dedicated thread for each operation. In
environments with a high number of concurrent operations, this approach leads
to excessive thread creation, consuming significant system resources and
potentially impacting server performance and stability.
This pull request addresses this inefficiency by introducing a more robust
and configurable timeout management system. The key enhancements include:
1. **Flexible Timeout Execution Strategies**: A new `TimeoutExecutor`
abstraction is introduced with two implementations:
* `PerOperationTimeoutExecutor`: Preserves the legacy behavior of
creating one thread per operation, ensuring backward compatibility.
* `ThreadPoolTimeoutExecutor`: A new, more efficient strategy that
utilizes a single, shared `ScheduledThreadPoolExecutor` for all operations.
This dramatically reduces the number of threads required for timeout management.
2. **Configuration for Control**: Users can now select the desired timeout
strategy via the `kyuubi.operation.timeout.executor.type` configuration
property (`per-operation` or `thread-pool`). The thread pool itself is also
configurable (`pool.size`, `pool.keepalive.time`).
3. **Improved Resource Management**: This patch fixes a potential resource
leak by ensuring that the timeout monitor is correctly shut down when an
operation is cancelled or closed. Furthermore, it integrates the lifecycle of
the shared `ThreadPoolTimeoutExecutor` with the `SessionManager`, guaranteeing
a clean shutdown and preventing resource leaks when the Kyuubi server stops.
These changes make Kyuubi's operation timeout handling more scalable,
efficient, and resilient, especially under heavy load.
### How was this patch tested?
A new comprehensive test suite, `TimeoutExecutorFactorySuite.scala`, has
been added to validate the new timeout management functionality. The tests
cover the following scenarios:
- Verification that the correct `TimeoutExecutor` implementation
(`PerOperationTimeoutExecutor` or `ThreadPoolTimeoutExecutor`) is created based
on the configuration.
- Validation of the singleton behavior of the `ThreadPoolTimeoutExecutor`
to ensure a single instance is shared across the application.
- Confirmation that new instances are correctly created for the
`per-operation` strategy.
- Testing the complete lifecycle of the `TimeoutExecutorFactory`,
including the proper shutdown of the underlying thread pool.
- A private, `@VisibleForTesting`-annotated `reset()` method was added to
the `TimeoutExecutorFactory` to tear down state between test cases, ensuring
test isolation and reliability.
- End-to-end functionality, including scheduling and cancellation of
timeout tasks, was also validated.
### Was this patch authored or co-authored using generative AI tooling?
No.
--
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
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
