[
https://issues.apache.org/jira/browse/HBASE-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917118#action_12917118
]
stack commented on HBASE-3029:
------------------------------
If your patch fixes HBASE-1937 and HBASE-2753 it'd help your case that the fix
for this issue is 'vital'.
> if scanner.next() throws IOE we dont do anything
> ------------------------------------------------
>
> Key: HBASE-3029
> URL: https://issues.apache.org/jira/browse/HBASE-3029
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.89.20100621
> Reporter: ryan rawson
> Fix For: 0.90.0
>
>
> During a scan if the HFile layer throws a unrecoverable IOE, for example,
> checksum exception, right now we throw the exception, and abort that RPC.
> But the scanner is not marked as closed, and the HFileScanner is left in a
> weird state. Subsequent calls get weird exceptions about ByteBuffers but
> this is an artifact of being left pointing at the end of the previous block
> when we should be into the next block.
> If the DFSClient throws an exception we have a choice:
> - make some efforts to retry
> - assume DFSClient has already tried, and thus this is a fatal type error
> The former case might be hard to implement, and the latter case needs to be
> handled so that subsequent calls to the scanner throw meaningful exceptions.
> Right now there is no way to early terminate a scanner from the
> server-side... HRegion$RegionScanner doesn't have a 'closed' flag nor does it
> have the ability to realize the scanner is now closed. The client side takes
> care of not iterating past the end of a scanner so in the normal case we dont
> iterate anymore once a scanner returns 'false'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
