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

Reply via email to