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)