hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5924) In the client code, don't wait for all the requests to be executed before resubmitting a request in error.
Date Wed, 06 Jun 2012 21:37:23 GMT

    [ https://issues.apache.org/jira/browse/HBASE-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290443#comment-13290443

stack commented on HBASE-5924:

@nkeywal Did you add the history in the first place?  Why is it safe to remove it now?

Thanks for redoing processBatchCallback.

On your three comments above, on 1., on the unused code, it may not be triggered by the test
suite -- that could just be bad test coverage -- but independent, there may have been a reason
for it.  If your review of processBatchCallback has it making no sense, by all means purge
it (as you have done).

On 2., the callback, it looks like you kept it.  I think that sensible.

On 3., can we move it to HTable?  Deprecate the current version in favor of the new HTable/HTableInterface
version?  Would that be too disruptive?

Any way you can add tests to prove your claims of improvement above (its hard to review for
that... but sounds like it at least works... going by it passing all unit tests... good on
you nkeywal)

> In the client code, don't wait for all the requests to be executed before resubmitting
a request in error.
> ----------------------------------------------------------------------------------------------------------
>                 Key: HBASE-5924
>                 URL: https://issues.apache.org/jira/browse/HBASE-5924
>             Project: HBase
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 0.96.0
>            Reporter: nkeywal
>            Assignee: nkeywal
>         Attachments: 5924.v5.patch, 5924.v9.patch
> The client (in the function HConnectionManager#processBatchCallback) works in two steps:
>  - make the requests
>  - collect the failures and successes and prepare for retry
> It means that when there is an immediate error (region moved, split, dead server, ...)
we still wait for all the initial requests to be executed before submitting again the failed
request. If we have a scenario with all the requests taking 5 seconds we have a final execution
time of: 5 (initial requests) + 1 (wait time) + 5 (final request) = 11s.
> We could improve this by analyzing immediately the results. This would lead us, for the
scenario mentioned above, to 6 seconds. 
> So we could have a performance improvement of nearly 50% in many cases, and much more
than 50% if the request execution time is different.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message