Sorry, my bad. It works over time.
It seems that the grpc starts with a default window size, then update
to a stable value according to options.
Wenbo Hu <huwenbo1...@gmail.com> 于2023年7月7日周五 23:32写道：
>
> Both my server and client are implemented in python now, Java Client
> may be in the future.
> Back pressure works, but not totally in control.
> Is there a way to configure how much memory used to read ahead for
> each grpc stream?
> For example, the client is calling do_get, then the client wants to
> limit the memory of FlightStreamReader, since the downstream
> processing is a time/memory consuming task. For its best option only
> read one record batch ahead with specified batch_size so that the
> minimum memory is used for streaming.
> Is "GRPC_ARG_HTTP2_STREAM_LOOKAHEAD_BYTES" used for that purpose?
> `generic_options=[("grpc.http2.lookahead_bytes", 100000)]`
> It seems not to take effect. I wrote a server sending the same record
> batch continuously 100 times, the client takes 1 sec to process each
> record batch read from do_get, no matter what value set, the server
> blocks at writing 14th/25th record batch...
>
> David Li <lidav...@apache.org> 于2023年7月7日周五 22:26写道：
> >
> > gRPC has backpressure built in. Is your server in Java or Python/C++?
> >
> > If in Java, the server needs to explicitly poll isReady to respect
> > backpressure. (This is rather wasteful, yes, and this will artificially
> > throttle your peak bandwidth because of a long-standing flaw in gRPC-Java.)
> >
> > If in Python/C++, the backpressure should be automatic (write calls will
> > block), so the client should just make sure not to read from the reader
> > until it actually wants data (there are lower-level options to tweak this,
> > IIRC)
> >
> > On Thu, Jul 6, 2023, at 23:18, Wenbo Hu wrote:
> > > Hi,
> > > I'm using arrow flight to transfer data in distributed system, but
> > > the lightning speed makes both client and server faces out of memory
> > > issue.
> > > For do_put and do_exchange method, the protocol provides stream
> > > metadata reader/writer for client/server exchange control messages
> > > along data stream.
> > > But do_get only returns a FlightDataStream without any extra
> > > control message can be used to communicate with each other.
> > > Also, the returned FlightDataStream is unaware of client
> > > canceling, while java has a cancel callback.
> > > My solution is to use do_exchange to replace do_get for client
> > > download data, or is there any better way to implement that?
> > >
> > > --
> > > ---------------------
> > > Best Regards,
> > > Wenbo Hu,
>
>
>
> --
> ---------------------
> Best Regards,
> Wenbo Hu,
--
---------------------
Best Regards,
Wenbo Hu,
