[ https://issues.apache.org/jira/browse/HBASE-17187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15710950#comment-15710950 ]
Anoop Sam John commented on HBASE-17187: ---------------------------------------- See RegionScannerImpl#next if (this.filterClosed) { throw new UnknownScannerException("Scanner was closed (timed out?) " + "after we renewed it. Could be caused by a very slow scanner " + "or a lengthy garbage collection"); } 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? Another place is this public boolean nextRaw(List<Cell> outResults, ScannerContext scannerContext) throws IOException { if (storeHeap == null) { // scanner is closed throw new UnknownScannerException("Scanner was closed"); } Just trying to understand the impact of the change fully. Tks. > 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)