hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17187) DoNotRetryExceptions from coprocessors should bubble up to the application
Date Tue, 29 Nov 2016 02:54:59 GMT

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

Enis Soztutar commented on HBASE-17187:

Thanks Josh for taking a look. 
bq. From the context of the Apache Phoenix test failure which caught this: making the RPC
30 more times (w/ default configs) is not-ideal.
We are using the default num of retries only in the case where the exception is thrown is
NOT a DNRIOE. Otherwise, we do not retry. The Phoenix test failure is throwing DNRIOE I think.

bq. 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.

> 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

View raw message