[ 
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
{code}
 if (e instanceof DoNotRetryIOException) {
3013                throw e;
3014              }
{code}
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?
{code}
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 client"
                + " scanner state for clients older than 1.3.", e);
          }
{code}
Also this is a resent fix
{code}
if (e instanceof CorruptHFileException || e instanceof FileNotFoundException) {
            throw new DoNotRetryIOException(e);
          }
{code}
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
(v6.3.4#6332)

Reply via email to