[
https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026202#comment-15026202
]
Jesse Yates commented on HBASE-14703:
-------------------------------------
Hey [~chenheng], can you attach that as a full patch? The way I find people
using addendums is generally for two things: (1) bug fixes immediately after
the fact, (2) helping to show changes. For instance, I used it previously to
show how you go follow up, but its a large change and it would have been hard
to keep track of how it fit onto the base patch, were it a single patch. For
smaller changes, especially that aren't expected to be committed, a new patch
and version is fine, and for really small changes - checkstyles, spelling, etc
- doing point patches is ok (so a 7.1).
The functional problem in particular here is that QA won't by able to handle
addendums, so making it patch available doesn't actually run the test :(
> 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
>
>
> 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)
