Alex-PLACET opened a new issue, #55396: URL: https://github.com/apache/arrow/issues/55396
### Describe the enhancement requested `FlightServerBase` serves every RPC on a gRPC worker thread that the handler occupies until it returns. A handler that waits on I/O, a query, a remote fetch, a queue, holds that thread for the whole wait, so throughput is bounded by the gRPC thread pool rather than by the work actually in flight. Add an async server, `AsyncGenericFlightServerBase`, whose handlers return `arrow::Future` and never hold a gRPC thread while waiting, served through gRPC's generic callback API (`grpc::CallbackGenericService`). ## Motivation The synchronous transport has three consequences that cannot be fixed inside it: 1. **Thread occupancy**: Every in-flight RPC owns a gRPC worker thread for its whole duration. Concurrent slow RPCs exhaust the pool and delay unrelated calls. 2. **Thread-pool growth is the only backpressure valve**: gRPC adds at most ~1 thread per second (hard-coded in gRPC code), so a burst of slow calls degrades sharply instead of degrading slowly and it leads to thread over-subscription. 3. **Handlers cannot express "later"**: `DoGet`, `GetFlightInfo`, `DoAction` etc. must produce their answer before returning. Producing it incrementally, or off-thread, means blocking a thread or hand-rolling a thread pool inside every server. Clients already have an async path (`FlightClient` async calls), the server side has no counterpart. ### Component(s) C++ -- 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]
