[
https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022589#comment-15022589
]
Jesse Yates commented on HBASE-14703:
-------------------------------------
Maybe [~apurtell] can give us some advice on the compatibility story here (I
forget :-/).
I think we can just do the fix in master as that cuts a new major release.
Worst case is you lose stats until both sides of the wire are upgraded. We
would also remove the public Result#getStats() method as that again becomes an
internal value, but I'm not sure if we can do that in a major release. Further,
I don't know how valuable it is to backport except some of the cleanup from
removing mutateRows statistics tracking and the statsTrackingRpcController
(since they never gets used anyways).
TL;DR on the JIRA so far:
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(?).
> 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.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)
