hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Heng Chen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14703) update the per-region stats twice for the call on return
Date Sat, 31 Oct 2015 05:18:28 GMT

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

Heng Chen commented on HBASE-14703:
-----------------------------------

IMO the point confused us is there are two ways we make communications with server.

One sync way we do RPC call directly and client will block.  
The other seems to be an async way using asyncProcess.  
So we have to collect stats in two places.   

But {{HTable.batch}}  method seems to be sync although it use asyncProcess 
{code}
  public void batch(final List<? extends Row> actions, final Object[] results)
      throws InterruptedException, IOException {
    AsyncRequestFuture ars = multiAp.submitAll(pool, tableName, actions, null, results);
    ars.waitUntilDone();
    if (ars.hasError()) {
      throw ars.getErrors();
    }
  }
{code}

So can we change all method to use AsyncProcess to do communications with server ?

As you mentioned,  {{HTable.mutateRow}} should return List<Result> instead of one Result.
Then we parse the information in {{StatsTrackingRpcRetryingCaller}}.
But If we use asyncProcess to do that, it seems to be more simple. 

Any concerns? 



> update the per-region stats twice for the call on return
> --------------------------------------------------------
>
>                 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-14703-start.patch, HBASE-14703.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)

Mime
View raw message