[ 
https://issues.apache.org/jira/browse/HBASE-18188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Enis Soztutar resolved HBASE-18188.
-----------------------------------
       Resolution: Fixed
    Fix Version/s: HBASE-14850

I've pushed v2 patch. 

> [C++] Fix Handling do not retry exceptions
> ------------------------------------------
>
>                 Key: HBASE-18188
>                 URL: https://issues.apache.org/jira/browse/HBASE-18188
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: HBASE-14850
>
>         Attachments: hbase-18188_v1.patch, hbase-18188_v2.patch
>
>
> Needed for HBASE-18061 and others. 
> Java client relies on the exception hierarchy for DoNotRetryExceptions, which 
> there is 40+ subtypes. The exceptions from the server side are rethrown in 
> the client side (ConnectionUtils.translateException, etc) and the rest of the 
> code deals with do-not-retry information by catching DoNotRetryIOException's 
> (thus relying on exception hierarchy). 
> This of course does not work on the C++ side, since we lack the info for the 
> java class types. In case the exception happens in the RPC response, the 
> server puts the do_not_retry information as a field in PB (see 
> ExceptionResponse::do_not_retry PB message). However, in other settings, we 
> just serialize the exception without do_not_retry information (see 
> ResultOrException PB message). In some other settings, we can raise 
> exceptions from the client-side (for example when table cannot be found in 
> meta). 
> We need a strategy to handle do-not-retry information uniformly, no matter 
> they are coming from client side or server side. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to