[jira] [Commented] (ARROW-5063) [Java] FlightClient should not create a child allocator

["Jacques Nadeau (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARROW-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16869732#comment-16869732 ] 

Jacques Nadeau commented on ARROW-5063:
---------------------------------------

I think we're trying to solve this wrong way. The idea that a client has its own allocator that is closed as it closes out to make sure it doesn't leak any memory is a good thing.

> [Java] FlightClient should not create a child allocator
> -------------------------------------------------------
>
>                 Key: ARROW-5063
>                 URL: https://issues.apache.org/jira/browse/ARROW-5063
>             Project: Apache Arrow
>          Issue Type: Improvement
>          Components: FlightRPC, Java
>            Reporter: Bryan Cutler
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> I ran into a problem when testing out Flight using the ExampleFlightServer with InMemoryStore producer. 
> A client will iterate over endpoints and locations to get the streams, and the example creates a new client for each location. The only way to close the allocator in the FlightClient is to close the FlightClient, which also closes the read channel.  If the location is the same for each FlightStream (as is the case for the InMemoryStore), then it seems like grpc will reuse the channel, so closing one read client will shutdown the channel and the remaining FlightStreams cannot be read.
> If an allocator was created by the owner of the FlightClient, then the client would not need to close it and this problem would be avoided. I believe other Flight classes do not create child allocators either, so this change would be consistent.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)