wangzhigang1999 opened a new issue, #7655: URL: https://github.com/apache/kyuubi/issues/7655
### 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 the existing issues and found no similar issue. ### Describe the feature Virtual threads were finalized in JDK 21 after several preview releases and have become a mature option for I/O-bound Java services. Kyuubi already supports running on JDK 21, but its server runtime does not use virtual threads yet. I propose adding optional virtual-thread support to the server-side Thrift Binary frontend. The initial scope covers only this frontend. Other frontends, server operation pools, engine RPC clients, and SQL engines remain unchanged. This gives the community a small and measurable starting point before considering broader adoption. ### Motivation Kyuubi is a multi-tenant gateway. Its frontend workers spend much of their lifetime waiting for JDBC clients, network I/O, session operations, or downstream engines. This workload fits the virtual-thread execution model better than a computation-heavy thread pool. A five-minute A/B benchmark on JDK 21 shows that virtual threads can reduce the server thread footprint without changing Spark SQL throughput or total CPU usage. Benchmark workload: - 500 JDBC sessions - 32 concurrent query workers - 30-second warm-up and 300-second measurement - 95% `SELECT 1` - 5% `SELECT sum(id) FROM range(100000)` - Spark `local[2]` - The same Kyuubi artifact and configuration in both runs - The frontend thread implementation was the only changed variable | Metric | Platform threads | Virtual threads | Difference | |---|---:|---:|---:| | Successful queries | 40,881 | 40,347 | -1.31% | | Throughput | 136.27 QPS | 134.49 QPS | -1.31% | | Latency p95 | 481.32 ms | 471.18 ms | -2.11% | | Pod CPU | 3.321 cores | 3.334 cores | +0.39% | | Kyuubi OS threads | 1,110 | 679 | **-38.83%** | | NMT thread reserved | 1116.1 MiB | 682.0 MiB | **-38.90%** | | NMT thread committed | 124.2 MiB | 74.5 MiB | **-40.03%** | | Average cgroup memory | 3190.3 MiB | 3138.9 MiB | -1.61% | | Kyuubi RSS | 637.1 MiB | 658.4 MiB | +3.35% | | Query failures | 0 | 0 | — | No virtual-thread pinning, server errors, or cgroup OOM kills were observed. The throughput and total CPU differences are small enough to treat as equivalent in this test. The measurable benefit is the reduction in Kyuubi OS threads and native thread memory. This change is not intended to accelerate Spark query execution. ### Describe the solution Add a server-only configuration: ```properties kyuubi.frontend.thrift.binary.virtual.threads.enabled=false ``` The configuration should be: - disabled by default; - immutable at session level; - limited to the Kyuubi Server Binary frontend; - effective only when running on a JDK that provides virtual threads. When enabled, the Binary frontend uses virtual threads for request handlers while preserving the configured maximum worker concurrency and task rejection behavior. Kyuubi still targets older Java class-file versions, so the implementation can access the JDK 21 virtual-thread APIs through reflection. Deployments running on older JDKs continue to use platform threads. This issue intentionally leaves engine-side virtual threads and other server executors out of scope. We can evaluate those paths separately if this first integration proves useful and maintainable. ### Additional context - JEP 444: https://openjdk.org/jeps/444 - Existing JDK 21 support issue: https://github.com/apache/kyuubi/issues/5314 - No existing Kyuubi issue was found for virtual-thread support. ### Are you willing to submit PR? - [x] Yes. I would be willing to submit a PR with guidance from the Kyuubi community to improve. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
