[ https://issues.apache.org/jira/browse/HBASE-18188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16044821#comment-16044821 ]
Ted Yu commented on HBASE-18188: -------------------------------- For location-cache.cc : {code} #include <folly/Logging.h> +#include <folly/Logging.h> {code} Drop duplicate include. For ExceptionUtil::IsJavaDoNotRetryException(), since for loop is terminated upon seeing the first DoNotRetryIOException, you can omit local variable do_not_retry. For ExceptionUtil::IsScannerOutOfOrder(), add comment on why ScannerResetException is included. {code} + // In case the exceptions is a RemoteException, do_not_retry information can come from {code} 'exceptions is' -> 'exception is' {code} + // All other DoNotRetryIOExceptions {code} I must have taken you a lot of time completing the list. In a follow on issue, we should explore writing a script which extracts such information from Java classes - new DoNotRetryIOExceptions may be added in the future. > [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 > Attachments: hbase-18188_v1.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.3.15#6346)