[
https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14999564#comment-14999564
]
Jesse Yates commented on HBASE-14703:
-------------------------------------
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)?
bq. it seems that processed flag has no relates with results
Ah, yes. For this, IIRC its all or nothing with the check so all you need to
send back is a single 'everything worked' flag, rather than a flag per
mutation, which would all be the same value. You added that with the
'processed' flag in the MultiResponse, but that's only going to be applicable
for the checkAndXXX cases, right?
I don't particularly like bolting on a processed flag onto the MulitResponse,
just to support this one case. Looking at the checkAndXXXX methods, they all
follow the same basic logic and return a MutateResponse#processed, except for
checkAndMutate. That makes me think we can do the same thing we are doing here
for the other checkAndXXX methods, but fork logic a little bit in AsyncProcess
to support that kind of processing instead (as a follow up JIRA, not here).
In the meantime, lets just focus on supporting the mutateRow and then later we
can fix checkAndMutate along with the other checkAndXXXX methods.
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.
Good stuff Heng Chen
> 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)
