[
https://issues.apache.org/jira/browse/HBASE-14703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998255#comment-14998255
]
Heng Chen commented on HBASE-14703:
-----------------------------------
{quote}
There seems to be a whole bunch of mechanics to get the 'processed' result out
of the AP - why can't you just use the results[] option and use that to get the
processed bit? If that works, you can throw out a ton of changes.
{quote}
Yeah, indeed, we can use results[] to get processed bit. But if we want to
unify get/scan through AsyncProcess, it is hard to process.
So i separated it with another interface in AP, and it seems that processed
flag has no relates with results.. wdyt?
{quote}
can we add an overloaded createAsyncRequestFuture() that doesn't take a
callable or a timeout? Would just call your version but with null, timeout
(saves a bunch of changes w/o loss of clarity)
{quote}
Sounds good, i will do it.
{quote}
why the switch in mutateRow around if there is a statistic tracker for
returning a value? seems like it simplify the code in the async process too.
{quote}
It is real tricky... Because i use ResponseConverter.getResults to convert
ClientProtos.MultiResponse into
{{org.apache.hadoop.hbase.client.MultiResponse}}.
And in ResponseConverter.getResults, it has this check.
{code}
if (actions.getActionCount() != actionResult.getResultOrExceptionCount()) {
throw new IllegalStateException("actions.getActionCount=" +
actions.getActionCount() +
", actionResult.getResultOrExceptionCount=" +
actionResult.getResultOrExceptionCount() + " for region " +
actions.getRegion());
}
{code}
In mutateRow server side, if we set option
{{hbase.client.backpressure.enabled}} OFF, it will return nothing to client.
There is no results, no exceptions... So above check will always failed.....
To fix this, i add a switch in mutateRow as you mentioned....
May be we can write another converter to convert response... wdyt?
> 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)
