Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 25 Nov 2015 06:51:10 +0000 (UTC)
From: "Heng Chen (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12908115.1445920888000.188032.1448434270980@Atlassian.JIRA>
In-Reply-To: <JIRA.12908115.1445920888000@Atlassian.JIRA>
References: <JIRA.12908115.1445920888000@Atlassian.JIRA>
 <JIRA.12908115.1445920888693@arcas>
Subject: [jira] [Comment Edited] (HBASE-14703) not collect stats when call
 HTable.mutateRow
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Heng Chen edited comment on HBASE-14703 at 11/25/15 6:50 AM:
-------------------------------------------------------------

{quote}
 It makes the code change we are putting in bigger, but doesn't really add any more clarity
{quote}
As for AbstractMultiCallable,  if you think it has too much levels.  Maybe we can unify it with PayloadCarryingServerCallable


was (Author: chenheng):
{quote}
 It makes the code change we are putting in bigger, but doesn't really add any more clarity
{quote}
I don't think so.  Indeed, if we just want to fix this issue as title, it is easy and no need for this big change.  But as you said, we should do it in right way. 
Currently logic is confused,  there are two path to communicate with server and statistics information store in PB result, it is not reasonable. I think we should make it clear.
After HBASE-14693,  there are more statistics we need to collect,  i think we should support an unify way to do it.  wdyt?

As for AbstractMultiCallable,  if you think it has too much levels.  Maybe we can unify it with PayloadCarryingServerCallable

> 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
>             Fix For: 2.0.0
>
>         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-v6_with-check-and-mutate.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-addendum.patch, HBASE-14703_v6.patch, HBASE-14703_v7.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)