In addition to Arrow Flight we have other gRPC APIs that work together as a whole. For example, the API client establishes a session with the server. Then the client tells the server to create a derivative data stream by filtering/joining/computing/etc several source streams. The server will keep this derivative stream available as long as the session exists. This session is kept alive with a heartbeat. So a small part of this system requires a regular (but not overwhelming) heartbeat. If this derivative stream has any data source that is live (aka regularly updating) then the derivative is also live. The API client would likely want to subscribe to the derivative stream, but still needs to heartbeat. The subscription (communicated via Flight's DoExchange) should be able to last forever. Naturally, this API pattern is simply better suited to the async pattern.
Ideally, we could re-use the same http2 connections, task queue and/or thread-pool between the arrow flight api and the other grpc apis (talking to the same endpoint). The gRPC callback pattern in Java is nice; it's a bit of a shame that gRPC hasn't settled on a c++ callback pattern. These are the kinds of ideas that it enables: - Subscribe to multiple ticking sources simultaneously. - Can have multiple gRPC requests outstanding at the same time (particularly useful if server is in a remote data center with high RTT). - Can communicate with multiple remote hosts simultaneously. - In general, enables the client to be event driven. Note that our clients tend to be light; they typically listen to derived data and then act based on the information without further computation locally. The gRPC c++ async library does indeed look a bit under-documented. There are a few blog posts that highlight some of the surprises, but async behavior is a requirement for what we're working on. (for async-cpp-grpc surprises see: https://www.gresearch.co.uk/article/lessons-learnt-from-writing-asynchronous-streaming-grpc-services-in-c/ ). Nate On Wed, Jun 2, 2021 at 8:44 PM David Li <lidav...@apache.org> wrote: > Hey Nate, > > I think there's an open JIRA for something like this. I'd love to have > something that plays nicely with asyncio/trio in Python and is hopefully > more efficient. (I think it would also let us finally have per-message > timeouts instead of only a per-call deadline.) There are some challenges > though, e.g. we wouldn't expose gRPC's event loop directly so that we could > support other transports, but then that leaves more things to design. I > also recall the async C++ APIs being very underdocumented, I get the sense > that they aren't actually used except to improve some benchmarks. I'll note > for instance gRPC in Python, which offers async support, uses the "core" > APIs directly and doesn't use anything C++ offers. > > But long story short, if you're interested in this I think it would be a > useful addition. What sorts of things would it enable for you? > > -David > > On Wed, Jun 2, 2021, at 16:20, Nate Bauernfeind wrote: > > It seems to me that the c++ arrow flight implementation uses only the > > synchronous version of the gRPC API. gRPC supports asynchronous message > > delivery in C++ via a CompletionQueue that must be polled. Has there been > > any desire to standardize on a solution for asynchronous use cases, > perhaps > > delivered via a provided CompletionQueue? > > > > For a simple async grpc c++ example you can look here: > > > https://github.com/grpc/grpc/blob/master/examples/cpp/helloworld/greeter_async_client.cc > > > > Thanks, > > Nate > > > > -- > > --
