hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Yang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-18121) Scanner id should be reset when ScannerCallable reload the location
Date Fri, 26 May 2017 07:41:04 GMT

    [ 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)

Mime
View raw message