[
https://issues.apache.org/jira/browse/HBASE-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16025937#comment-16025937
]
Phil Yang commented on HBASE-18121:
-----------------------------------
It is not easy to fix because we use callWithRetries in ScannerCallable and
only when we get DoNotRetryIOException we have logic to reset scanner id and
start row to make sure we are continuing the scanning. When the next() call has
some exception, now we only retry in lower level by reload the meta and find
the new server. Even if we reset the scanner id we still only have a Scan with
wrong startRow.
So we can fix HBASE-18122 first. After that although the logic is still wrong,
we will get an UnknownScannerException and we can retry correctly and will not
read any wrong data. The only weakness is one time useless rpc request.
> Scanner id should be reset when ScannerCallable reload the location
> -------------------------------------------------------------------
>
> Key: HBASE-18121
> URL: https://issues.apache.org/jira/browse/HBASE-18121
> Project: HBase
> Issue Type: Bug
> Reporter: Phil Yang
> Assignee: Phil Yang
>
> If a scan rpc request failed, the RetryingCallable will retry by reload=true
> and may change the location because there may be a RS crash. However, the
> ScannerCallable will still use the previous scanner id and send to the new
> server. In new RS the scanner id is not related with the old RS. The most
> possible result is UnknowScannerException and client will retry and there
> will be one useless rpc. And there is a low probability that there is a
> scanner with same id in the new RS, the result will be totally wrong.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
