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