[
https://issues.apache.org/jira/browse/HIVE-16637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16005518#comment-16005518
]
Jason Dere commented on HIVE-16637:
-----------------------------------
I think for this to work (basically, for the ChunkedInputStream always read the
next chunk length after it's done reading a chunk), the ChunkedInputStream
would have to do read ahead for the very first chunk size before any calls to
read() have occurred, probably during the constructor. However, this would mean
that getRecordReader() (which constructs the ChunkedInputStream) becomes a
blocking call .. and potentially as long as the fragment execution if there are
no resulting rows returned by the fragment. Which I don't think is a good thing
.. unless there is another approach you are suggesting?
I'm not sure if trying to read beyond the end of input is incorrect - it is
valid to do
{code}while (in.read() != -1) { }{code}
> Improve end-of-data checking for LLAP input format
> --------------------------------------------------
>
> Key: HIVE-16637
> URL: https://issues.apache.org/jira/browse/HIVE-16637
> Project: Hive
> Issue Type: Bug
> Components: llap
> Reporter: Jason Dere
> Assignee: Jason Dere
> Attachments: HIVE-16637.1.patch
>
>
> The existing end of stream checking in the record reader is too forgiving of
> errors and does not recognize situations where the server connection has
> closed abruptly like HIVE-14093.
> Try to add a way to indicate that we have truly hit the end of the stream.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
