hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17187) DoNotRetryExceptions from coprocessors should bubble up to the application
Date Fri, 02 Dec 2016 01:22:58 GMT

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

Enis Soztutar commented on HBASE-17187:
---------------------------------------

bq. So here we throw UnknownScannerException and RsRpcServices catch IOE and the new code
is having a DNRIOE check and now we will throw back UnknownScannerException not ScannerResetException.
I think that is ok. Or not?
That is fine. In the client-side (ClientScanner), {{UnknownScannerException}} and {{ScannerResetException}}
is treated the same way. We have introduced ScannerResetException rather than UnknownScannerException,
because the two are semantically different. The way they are treated in the client is the
same. UKSE is thrown when the client asks for a scanner, but we cannot find it. SRE is thrown
when the client was continuing a *known* scanner, but due to some exception, we have reset
the scanner, thus telling the client that the current scanner that it was using is already
closed by us. In the above places, which one to use is debatable. We can keep throwing UKSE
I think. 

bq. Just trying to understand the impact of the change fully. Tks.
No worries at all. 




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

Mime
View raw message