[ https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14982000#comment-14982000 ]
Heng Chen commented on HBASE-14703: ----------------------------------- {quote} Thinking about it, it would be a hairy patch to insert a mock stats into the connection to check for a bug from a class that will no longer exist. {quote} Excuse me, are you talking about {{TestClientPushback}} ? Currently, in {{TestClientPushback}}, there are no mock stats, ServerStats is calculated by signals pushed back by MiniHBaseCluster. Is it NOT the real purpose of this testcase? As you mentioned {quote} you could mock out the server stats to specify the load it should be getting and then ensure that the backoff time is the same. {quote} Yeah, we can mock serverStats which client used to calculated backoffTime. But if we do it, we can't test the situation which client NOT collect server pushback. > 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.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)