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