[jira] [Commented] (ARROW-5063) [Java] FlightClient should not create a child allocator
[ https://issues.apache.org/jira/browse/ARROW-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16869736#comment-16869736 ] lidavidm commented on ARROW-5063: - Since we couldn't reproduce the gRPC behavior, maybe I can rollback the change to the client and just keep the tests? > [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)
[jira] [Commented] (ARROW-5063) [Java] FlightClient should not create a child allocator
[ https://issues.apache.org/jira/browse/ARROW-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
