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] [Updated] (HBASE-14703) not collect stats when call HTable.mutateRow
Date Thu, 17 Dec 2015 01:13:46 GMT

     [ https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Heng Chen updated HBASE-14703:
------------------------------
    Description: 
We are trying to fix the stats implementation, by moving it out of the Result object and into
an Rpc payload (but not the 'cell payload', just as part of the values returned from the request).
This change will also us use easily switch to AsyncProcess as the executor, and support stats,
for nearly all the rpc calls. However, that means when you upgrade the client or server, you
will lose stats visibility until the other side is upgraded. We could keep around the Result
based stats storage to accommodate the old api and send both stats back from the server (in
each result and in the rpc payload).
Note that we will still be wire compatible - protobufs mean we can just ride over the lack
of information.
The other tricky part of this is that Result has a non-InterfaceAudience.Private getStatistics()
method (along with two InterfaceAudience.Private addResults and setStatistics methods), so
we might need a release to deprecate the getStats() method before throwing it out?



  was:
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?



> 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_v10.patch,
HBASE-14703_v10.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, HBASE-14703_v8.patch, HBASE-14703_v9.patch
>
>
> We are trying to fix the stats implementation, by moving it out of the Result object
and into an Rpc payload (but not the 'cell payload', just as part of the values returned from
the request). This change will also us use easily switch to AsyncProcess as the executor,
and support stats, for nearly all the rpc calls. However, that means when you upgrade the
client or server, you will lose stats visibility until the other side is upgraded. We could
keep around the Result based stats storage to accommodate the old api and send both stats
back from the server (in each result and in the rpc payload).
> Note that we will still be wire compatible - protobufs mean we can just ride over the
lack of information.
> The other tricky part of this is that Result has a non-InterfaceAudience.Private getStatistics()
method (along with two InterfaceAudience.Private addResults and setStatistics methods), so
we might need a release to deprecate the getStats() method before throwing it out?



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

Mime
View raw message