You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Heng Chen (JIRA)" <ji...@apache.org> on 2015/11/20 10:59:11 UTC

[jira] [Comment Edited] (HBASE-14703) not collect stats when call HTable.mutateRow

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

Heng Chen edited comment on HBASE-14703 at 11/20/15 9:59 AM:
-------------------------------------------------------------

Update a patch based on your last patch, and i create a diff base on your patch.
And i aslo upload the real patch v6.
 * Remove some unused code.  But not remove RegionLoadStats in ResultOrException for PB parser not crashed when user upgrade cluster.
 * Unify RS multi response for mutateRow and other calls  which use multi interface currently (put/puts/gets). So we can unify different process path in AP.

I try to unify checkAndMutate and AP,  but failed.  
The reason is i have no idea how to get processed flag if not add one option in MultiResponse.
I try to pass results[] into AP.submit,  but found it can't pass test case TestCheckAndMutate.  
Maybe we should add process flag back into MultiResponse.  wdyt?





was (Author: chenheng):
Update a patch based on your last patch, and i create a diff base on your patch.
 * Remove some unused code.  But not remove RegionLoadStats in ResultOrException for PB parser not crashed when user upgrade cluster.
 * Unify RS multi response for mutateRow and other calls  which use multi interface currently (put/puts/gets). So we can unify different process path in AP.

I try to unify checkAndMutate and AP,  but failed.  
The reason is i have no idea how to get processed flag if not add one option in MultiResponse.
I try to pass results[] into AP.submit,  but found it can't pass test case TestCheckAndMutate.  
Maybe we should add process flag back into MultiResponse.  wdyt?




> not collect stats when call HTable.mutateRow 
> ---------------------------------------------
>
>                 Key: HBASE-14703
>                 URL: https://issues.apache.org/jira/browse/HBASE-14703
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Heng Chen
>            Assignee: Heng Chen
>         Attachments: HBASE-14702_v5.2_addendum-addendum.patch, HBASE-14703-5.2-addendum.patch, HBASE-14703-async.patch, HBASE-14703-start.patch, HBASE-14703-v4.1.patch, HBASE-14703-v4.patch, HBASE-14703.patch, HBASE-14703_v1.patch, HBASE-14703_v2.patch, HBASE-14703_v3.patch, HBASE-14703_v5.1.patch, HBASE-14703_v5.2.patch, HBASE-14703_v5.patch, HBASE-14703_v6.patch
>
>
> In {{AsyncProcess.SingleServerRequestRunnable}}, it seems we update serverStatistics twice.
> The first one is that we wrapper {{RetryingCallable}}  by {{StatsTrackingRpcRetryingCaller}}, and do serverStatistics update when we call {{callWithRetries}} and {{callWithoutRetries}}. Relates code like below:
> {code}
>   @Override
>   public T callWithRetries(RetryingCallable<T> callable, int callTimeout)
>       throws IOException, RuntimeException {
>     T result = delegate.callWithRetries(callable, callTimeout);
>     return updateStatsAndUnwrap(result, callable);
>   }
>   @Override
>   public T callWithoutRetries(RetryingCallable<T> callable, int callTimeout)
>       throws IOException, RuntimeException {
>     T result = delegate.callWithRetries(callable, callTimeout);
>     return updateStatsAndUnwrap(result, callable);
>   }
> {code}
> The secondary one is after we get response, in {{receiveMultiAction}}, we do update again. 
> {code}
> // update the stats about the region, if its a user table. We don't want to slow down
> // updates to meta tables, especially from internal updates (master, etc).
> if (AsyncProcess.this.connection.getStatisticsTracker() != null) {
>   result = ResultStatsUtil.updateStats(result,
>   AsyncProcess.this.connection.getStatisticsTracker(), server, regionName);
> }
> {code}
> It seems that {{StatsTrackingRpcRetryingCaller}} is NOT necessary,  remove it?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)