[ https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14979630#comment-14979630 ]
Jesse Yates commented on HBASE-14703: ------------------------------------- Hmm, I remember this code being a bit tricky with a couple of code paths needing to be covered to ensure the stats are collected. I would like to see a test change, probably in TestClientPushback for actually verifying the amount of pushback we should see, so instead of: {code} long backoffTime = backoffPolicy.getBackoffTime(server, regionName, serverStats); assertNotEquals("Reported load does not produce a backoff", backoffTime, 0); {code} 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. If the values are as expected, then we should be good to go. I'll take a deeper look at the code tomorrow to see how it all fits together - right now its way out RAM, in cold storage > 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)