[
https://issues.apache.org/jira/browse/ARROW-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16183263#comment-16183263
]
ASF GitHub Bot commented on ARROW-1613:
---------------------------------------
Github user siddharthteotia commented on the issue:
https://github.com/apache/arrow/pull/1138
I am not sure of the potential impacts on downstream consumers (like Dremio
and others) of Arrow.
Is it just about explicitly closing the channel after closing the stream
The way I look at close() operation is that it should typically release all
resources. So the caller should consciously use this operation. It's counter
intuitive to me that after close(), additional operation(s) is/are needed to
release other resources (in this case it would be the channel)
How about overriding the close() operation for specialized semantics for
the scenarios @BryanCutler mentioned?
Thoughts? cc @jacques-n
> [Java] ArrowReader should not close the input ReadChannel
> ---------------------------------------------------------
>
> Key: ARROW-1613
> URL: https://issues.apache.org/jira/browse/ARROW-1613
> Project: Apache Arrow
> Issue Type: Bug
> Components: Java - Vectors
> Reporter: Bryan Cutler
> Assignee: Bryan Cutler
> Labels: pull-request-available
>
> Currently, {{ArrowReader.close()}} will close resources (VectorSchemaRoot and
> Dictionary Vectors) and also close the input ReadChannel, or InputStream for
> ArrowStreamReader. Closing of the ReadChannel should be done by what ever
> created it because it might need to be reused.
> If this not possible, an alternative could be to add a method
> {{ArrowReader.end()}} that will close resources but not the ReadChannel.
> Then {{end()}} could be called instead of {{close()}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
