[
https://issues.apache.org/jira/browse/HBASE-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289591#comment-13289591
]
nkeywal commented on HBASE-5924:
--------------------------------
Bumped the priority to major to make clear it's a complete rewriting. Tests are
in progress, I will push a version soon anyway to get feedback.
Changes:
Analyze the replies as they come, not in the initial request order
Replay the failed request immediately, not when we have all the replies
Reuse the actions in case of errors instead of recreating the objects
Don't iterate on the results list to find the errors
Don't reiterate on the results list to detail the errors.
Note that I removed the 'updateHistory' list but not the code in case the
feedback shows it should still be used.
Even if it's a one to one implementation, it's preferable to add specific
tests. Will do in a later update. And the current implementation stayed in
HConnectionManager and kept its callback. Happy to change this.
> 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
>
> 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
