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

Josh Elser commented on HBASE-17187:
------------------------------------

[~enis], your patch looks like it would work to me. Some thoughts in reading 
over it:

* Great comments in-line. These do a fantastic job explaining why it is the way 
it is.
* From the context of the Apache Phoenix test failure which caught this: making 
the RPC 30 more times (w/ default configs) is not-ideal.
* Long-term, makes me think defining exceptions that will come out of 
{{RSpcServices#scan(...)}} is a good idea for coprocessors to hook into for 
more "application-level" exceptions. e.g. something like 
{{UnknownScannerException}}, {{ScannerResetException}}, and a 
{{CoprocessorApplicationException}} which we would know to propagate and 
clients could know to not retry. Essentially, helps us remove some of the 
ambiguity around DNRE that you explained.

> 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