hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17187) DoNotRetryExceptions from coprocessors should bubble up to the application
Date Tue, 29 Nov 2016 07:08:58 GMT

    [ https://issues.apache.org/jira/browse/HBASE-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15704457#comment-15704457

Anoop Sam John commented on HBASE-17187:

UnknownScannerException etc are DNRIOE only.  So addition of this
 if (e instanceof DoNotRetryIOException) {
3013	            throw e;
3014	          }
means we will not throw back ScannerResetException now?

So which all IO exception will come under and converted to ScannerResetException now?   Seems
we wanted to consider UnknownScannerException only?
if (VersionInfoUtil.hasMinimumVersion(context.getClientVersionInfo(), 1, 4)) {
            // 1.4.0+ clients know how to handle
            throw new ScannerResetException("Scanner is closed on the server-side", e);
          } else {
            // older clients do not know about SRE. Just throw USE, which they will handle
            throw new UnknownScannerException("Throwing UnknownScannerException to reset the
                + " scanner state for clients older than 1.3.", e);
Also this is a resent fix
if (e instanceof CorruptHFileException || e instanceof FileNotFoundException) {
            throw new DoNotRetryIOException(e);
Now after ur code addition CorruptHFileException  is handled by not FNFE.  Would have been
best if we converted FNFE to HBase specific (HFileNotFoundE) and thrown up the layers.  But
not directly related to this patch any way.

> DoNotRetryExceptions from coprocessors should bubble up to the application
> --------------------------------------------------------------------------
>                 Key: HBASE-17187
>                 URL: https://issues.apache.org/jira/browse/HBASE-17187
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>         Attachments: hbase-17187_v1.patch
> In HBASE-16604, we fixed a case where scanner retries was causing the scan to miss some
data in case the scanner is left with a dirty state (like a half-seeked KVHeap). 
> The patch introduced a minor compatibility issue, because now if a coprocessor throws
DNRIOE, we still retry the ClientScanner indefinitely. 
> The test {{ServerExceptionIT}} in Phoenix is failing because of this with HBASE-16604.

This message was sent by Atlassian JIRA

View raw message