[
https://issues.apache.org/jira/browse/ARROW-9587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17170806#comment-17170806
]
David Li commented on ARROW-9587:
---------------------------------
Another problem this causes is a spurious IllegalStateException from gRPC if a
DoPut sends an error - that ends the gRPC call, but then when Flight closes the
FlightStream, the FlightStream tries to cancel the call, resulting in a
double-close of the gRPC call.
> [FlightRPC][Java] Clean up DoPut/FlightStream memory handling
> -------------------------------------------------------------
>
> Key: ARROW-9587
> URL: https://issues.apache.org/jira/browse/ARROW-9587
> Project: Apache Arrow
> Issue Type: Improvement
> Components: FlightRPC, Java
> Affects Versions: 1.0.0
> Reporter: David Li
> Assignee: David Li
> Priority: Major
>
> We've been running into issues with DoPut in Java. In particular:
> * Closing a FlightStream without draining it should not send a cancellation
> to the other side. A server will have sent an explicit error message, or will
> simply just not want to read the entire stream. A client should explicitly
> cancel/gRPC will cancel for you anyways when you end the call. Also, the
> gRPC call may already have ended and cancelling the call may result in a
> runtime exception.
> * The server should close/clean up things properly in DoPut (it should act
> like DoExchange and tie closing of the stream to the onCompleted/onError
> callbacks). Otherwise trying to use it with ARROW-9586 becomes impossible
> (you need to close the FlightStream before ending the call, or you'll close
> the per-call allocator before you close the FlightStream)
> I think this also ties into flakiness in unit tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
