[
https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15000072#comment-15000072
]
Heng Chen commented on HBASE-14703:
-----------------------------------
{quote}
Looking closer at the patch, I'm a bit concerned with how retries will work.
Since the AsyncProcess handles retries, we shouldn't be calling the
callable.callWithRetries, right? Then we would get two sets of retries with the
callable nested under the AsyncProcess. Can't we just use the standard AP
timeout then as well (its not something the user changes per-call)?
{quote}
Indeed, it is a problem. I have thought that callable.callWithRetries could
handle timeout option inside, but i found that we can use the standard AP
timeout to do it as you mentioned. I will do it.
{quote}
that's only going to be applicable for the checkAndXXX cases, right?
{quote}
yeah, it is only for checkAndXXX.
{quote}
In the meantime, lets just focus on supporting the mutateRow and then later we
can fix checkAndMutate along with the other checkAndXXXX methods.
{quote}
OK. Currently, we can leave checkAndMutate without AP before we can handle it
more gracefully...
{quote}
For mutateRow, maybe its better to just check to see if it has any Results,
rather than checking to see if there is a statistic tracker? It ties more into
why the ResponseConverter won't work, rather than why there are no Results in
the response and leave that information in a comment around the check for the
count of results.
{quote}
Sounds reasonable, i will do it.
Other tips:
* currently, in mutateRow server side, if hbase.client.backpressure.enabled
ON, response.getRegionActionResultCount() will be more than
request.getRegionActionCount(). I fix it in server side, so we can pass check
in ResponseConverter.
* similarly, because of no results in response of mutateRow, we can't add
loadstats into result in ResponseConverter. I fix it too.
> 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
> Attachments: HBASE-14703-async.patch, HBASE-14703-start.patch,
> HBASE-14703.patch, HBASE-14703_v1.patch, HBASE-14703_v2.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)
