It should be safe. The fast-read path has pretty much always been enabled and 
I'm not aware of issues it causes. (The fast-read path simply calls an internal 
gRPC method to avoid bouncing through byte[], but we're still copying the data 
into Arrow, now that I look at it.)

The fast-write path is not relevant here, but that's the one that is trickier 
to use. We should make sure the optimization(s) are properly documented, since 
looking through it's not really explained what the consequences are (or at 
least the flag in ArrowMessage should reference setUseZeroCopy, and we should 
have a doc page for these env vars analogous to ARROW-15617 for C++.)

On a side note, digging around to refresh my memory shows that gRPC Java 
*finally* introduced a zero-copy Protobuf deserialization path. I'm not sure 
it's quite relevant for us, since we still need to get the data into an 
off-heap buffer in the end, but I need to take a closer look. (See 
grpc/grpc-java#8102.)

-David

On Tue, Feb 15, 2022, at 13:12, James Duong wrote:
> Thanks for the tip David.
> 
> Do you know if zero copy can be used safely on the ServerStreamListener when 
> using the VectorUnloader/Loader pattern above?
> 
> On Mon, Feb 14, 2022 at 9:38 AM David Li <[email protected]> wrote:
>> __
>> Hey Alex,
>> 
>> Basically, you should call start() exactly once, as you noticed, it sends 
>> the initial schema message.
>> 
>> If the VectorSchemaRoot is not stable, what you should do is create your own 
>> root with the same schema, and use VectorUnloader/VectorLoader to transfer 
>> data from the source root to the root used by Flight.
>> 
>> Does that make sense? This would be good to add to the Arrow Java cookbook 
>> (at least, the VectorLoader/Unloader part).
>> 
>> -David
>> 
>> On Mon, Feb 14, 2022, at 12:27, Alex McRae (CW) wrote:
>>> Hi team,
>>> 
>>> We are currently building a Flight service which proxies requests in Java. 
>>> We are currently getting getStream working on the FlightProducer.
>>> 
>>> The code looks similar to this
>>> 
>>> public *void* getStream(CallContext context, ServerStreamListener listener) 
>>> {
>>>     FlightStream stream = *this*.client.getStream(ticket);
>>>     *while* (flightStream.next()) {
>>>         *if* (!flightStream.hasRoot()) { *break*; }
>>>         
>>>         listener.start(flightStream.getRoot(), 
>>> flightStream.getDictionaryProvider());
>>>         listener.putNext();
>>>     }
>>>     listener.completed();
>>> }
>>> 
>>> 
>>> We are running into issues understanding if this is valid usage? I have 
>>> looked at the OutBoundStreamListenerImpl.java file and it looks like 
>>> calling start() on the listener causes it to resend some schema messages.
>>> We are trying to understand how to handle the case where 
>>> flightStream.getRoot() returns a different VectorSchemaRoot than the 
>>> previous call.
>>> 
>>> For more context we have also tried
>>> public *void* getStream(CallContext context, ServerStreamListener listener) 
>>> {
>>>     FlightStream flightStream = *this*.client.getStream(ticket);
>>>     listener.start(flightStream.getRoot(), 
>>> flightStream.getDictionaryProvider());
>>>     *while* (flightStream.next()) {
>>>         *if* (!flightStream.hasRoot()) { *break*; }
>>>         
>>>         listener.putNext();
>>>     }
>>>     listener.completed();
>>> }
>>> But ran into issues with the connection not closing, we believe this to be 
>>> due to the VectorSchemaRoot changing on flightStream.next() calls. We 
>>> believe this is a issue because we are sharing the root with both the 
>>> FlightStream and ServerStreamListener.
>>> https://github.com/dremio-hub/arrow-flight-client-examples is the client we 
>>> are using to test this end to end.
>>> 
>>> Please let me know if you can provide any clarity, I would be happy to 
>>> update the documentation afterwards.
>>> 
>>> Sincerely,
>>> Alex McRae
>>> [email protected]
>> 
> 
> 
> -- 
> *James Duong*
> Lead Software Developer
> Bit Quill Technologies Inc.
> Direct: +1.604.562.6082 | [email protected]
> https://www.bitquilltech.com
> 
> 
> This email message is for the sole use of the intended recipient(s) and may 
> contain confidential and privileged information.  Any unauthorized review, 
> use, disclosure, or distribution is prohibited.  If you are not the intended 
> recipient, please contact the sender by reply email and destroy all copies of 
> the original message.  Thank you.

Reply via email to